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DescHption 

The present Invention relates to a digital data processing system and, more particularly, to a 
multiprocessor digital data processing system suitable for use in a data processing network and having a 
simplified, flexible user interface and flexible, multileveled internal mechanism. 

A general trend in the development of data processing systems has been towards systems suitable for 
use In Interconnected data processing networks. Another trend has been towards data processing systems 
wherein the internal structure of the system Is flexible, protected from users, and effectively invisible to the 
user and wherein the user is presented v^h a flexible and simplified interface to the system. 

Certain problems and shortcomings affecting the realization of such a data processing system have 
appeared repeatedly in the prior art and must be overcome to create a data processing system having the 
above attributes. These prior art problems and limitations include the following topics. 

Rrst, the data processing systems of the prior art have not provided a system wide addressing system 
suitable for use in common by a large number of data processing systems interconnected into a network. 
Addressing systems of the prior art have not provided sufficiently large address spaces and have not 
allowed information to be permanently and uniquely Identified. Prior addressing systems have not made 
provisions for Information to be located and identified as to type or format, and have not provided 
suffident granularity. In addition, prior addressing systems have reflected the physical structure of 
pariScular data processing systems. That is, the addressing systems have been dependent upon whether a 
particular computer was, for example, an 8, 16, 32, 64 or 128 bit machine. Since prior data processing 
systems have incorporated addressing medianisms wherein the actual physical structure of the processing 
system is apparent to the user, the operations a user could perform have been limited by tiie addnes^ng 
mechanisms. In addition, prior processor systems have operated as fixed word length machines^ further 
limiting user operations. 

Prior data processing systems have not provided effective protection mechanisms preventing one user 
from effecting another user's data and programs without permission. Such protection mechanisms have 
not allowed unique, positive identification of users requesting access to Information, or of information, nor 
have such mechanisms been sufficiently flexible In operation. In addition, access rights have pertained to 
the users rather than to the infomiation, so that control of access rights has been difficult Rnally, prior art 
protection mechanisms have allowed the use of 'Trojan Horse arguments". That is, users not having 
access rights to certain Information have been able to gain access to that infonnatlon through another user 
or procedure having such access rights. 

Yet another problem of the prior art Is that of providing a simple and flejdble user's interface to a data 
processing system. The character of user's interface to a data processing system is determined, in part, by 
the means by whidi a user refers to and identifies operands and procedures of the user's progrants and by 
the instruction structure of the system. Operands and procedures are customarily referred to and identified 
by some form of logical address having points of reference, and validity, only within a user's program. 
These addresses must be translated Into logical and physical addresses within a data processing system 
each time a program is executed, and must then be frequentiy retranslated or generated during execution 
of a program. In addition, a user must provide specific instructions as to data format and handling. As such 
reference to operands or procedures typically comprise a major portion of the instruction stream of the 
user's program and requires numerous machine translations and operations to implement. A user's 
interface to a conventional system Is thereby complicated, and the speed of execution of programs 
reduced, because of the complexity of the program referonces to operands and procedures. 

A data processing system's instruction structure includes both the instructions for controlling system 
operations and the means by w^ich these instructions are executed. Conventional data processing systems 
are designed to efficientiy execute instructions in one or two user languages, for example, FORTRAN or 
COBOL Programs written in any other language are not effidentiy executable. In addition, a user is often 
faced with diffioilt programming problems when using any high level language other than the particular 
one or two languages that a particular conventional system is designed to utilize. 

Yet another problem in conventional data processing systems is that of protecting the system's 
internal mechanisms, for example, stack mechanisms and internal control mechanisms, from accidental or 
malicious Interference by a user. 

Rnally, the Imemal structure and operation of prior art data processing systems have not been flexible, 
or adaptive, in structure and operation. That is, the Internal structure and operation of prior systems have 
not allowed the systems to be easily modified or adapted to meet particular data processing requirements. 
Such modifications may include changes in internal memory capacity, such as the addition or deletion of 
special purpose subsystems, for example, floating polm or array processors. In addition, such 
modifications have signiflcantiy effected the users interface with the system. Ideally, the actual physical 
structure and operation of the data processing system should not be apparent at the user interface. 

It has already been proposed (IBM Technical Disclosure Bulletin Vol. 22 No. 3 Aug. 1979 pp 
1286—1289) to maintain such a large address space that every object which is ever created can have a 
unique identifier. This requires a very large identifier field, e.g. 40 to 50 bits. 

The object of the present Invention is to Implement such a concept so that it may be applied across 
many computers geographically distributed and without requiring all computers to use the same 
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programming language. 

The system according to the invention h defined in the appended ciaims. 

ft ts known in virtual address machines to use name tables to provide logical addresses for translation 
to physical addresses {K\ar, Wichmann, "Mikroprognammierung" June 1975, especially pp. 15&— 163. 
176—179, 185—187, 195—205, 214—215) and this reference also discusses the emulation in software of 
different target machines. 

More specificalVr the embodiment of the invention descnbed in detail below provides a data 
processing system suitable for use in interconnected data processing networks, which Internal structure is 
flexibJe. protected from users, effectively invisible to users, and provides a flexible and simplified interface 
to users. The data processing system provides an addressing mechanism allowing permanent and unique 
identification of all infonmation generated for use in or by operation of the system, and an extremely large 
address space which is accessible to and common to all such data processing systems. The addressing 
mechanism provides addresses which are independent of the physical configuration of the system and 
allow information to be completely Identified, with a single address, to the bit granular level and with 
regard to information type or format The present invention fur^er provides a protection mechanism 
wherein variable access rights are associated with individual bodies of Information. Information, and users 
requesting access to information, are uniquely identified through the system addressing mechanism* The 
protection mechanism also prevents use of Trojan Horse arguments. And, the present invention provides 
an instruction structure wherdn high level user language instructions are transformed into dialect coded, 
uniform* intermediate level instructions to provide equal facility of execution for a pluraOty of user 
languages. Another feature is the provi^on of an operand reference mechanism wherein operands are 
referr^ to in user's programs by uniform format names which are transformed, by an intemal mechanism 
transparent to the user, into addresses. The present invention additionally provides multilevel control and 
stack mechanisms protecting the system's intemal mechanism from interference by users. Yet another 
feature Is a data processing system having a flexible internal structure capable of performing multiple, 
concun^nt operations and comprised of a plurality of separate, independent processors. Each such 
Independent processor has a separate microinstruction control and at least one separate and independent 
port to a central communications and memory node. The communications and memory node is also an 
Independent processor having separate and independent microinstruction control. The memory processor 
is intematly comprised of a plurality of independentiy operating, microinstruction controlled processors 
capable of performing multiple, concurrent memory and communications operations. The present 
invention also provides further data processing system structural and operational features for 
implementing the above features. 

it is thus advantageous to iricorporate.the present invention into a data processing system because the 
present invention provides addressing mechanisms suitable for use in large interconnected data 
processing networks. Additionally, the present invention is advantageous in that it provides an information 
protection mechanism suitable for use in large, interconnected data processing networks. The present 
invention is furtiier advantageous in that it provides a simplified, flexible, and more efHcient interface to a 
data processing system. The present invention is yet further advantageous In that it provides a data 
processing system which is equally effident with any user level language by providing a mechanism for 
referring to operands in user programs by uniform format names and instruction structure incorporating 
dialect coded, uniform format intermediate level instructions. Additionally, the present invention protects 
data processing system intemal mechanisms from user lnterfererK;e by providing muhitevel control and 
stack mechanisms. The present invention is yet furtiier advantageous in providing a flexible intemal 
system structure capable of performing multiple, concurrent operations, comprising a plurality of separate, 
independent processors, each having a separate microinstruction control and at least one separate and 
independ^t port to a central. Independent communications and memory processor comprised of a 
plurality of independent processors capable of performing multiple, corKnjrrent memory and 
communications operations. 

Other advantages and features of the present invention will be understood by those of ordinary skill in 
tiie art, after referring to the following detailed description of the preferred embodiments and drawings 
wherein. 

BRIEF DESCRIPTION OF DRAWINGS 
Rg. 1 is a partial block diagram of a computer system incorporating the present invention; 
Rg. 2 is a diagram illustrating computer system addressing structure of the present invention; 
Fig. 3 is a diagram illustrating the computer system instruction stream of the present invention; 
Rg. 4 is a diagram Illustrating the control structure of a conventional computer system; 
Rg. 4A is a diagram Illustrating the control structure of a computer system incorporating the present 
invention; 

Rg. 5 — Rg. A1 inclushre are diagrams all relating to the present invention; 
Rg. 5 is a diagram illustrating a stack mechanism; 

Rg. 6 IS a diagram illustrating procedures, procedure objects, processes, and virtual processors; 
Fig. 7 ts a diagram illustrating operating levels and mechanisms of the present computer; 
Rg. 8 is a diagram illustrating a physical implementation of processes and virtual processors; 
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Rg. 9 is a diagram illustrating a process and process stack objects; 
Fig. 10 is a diagram illustrating operation of macrostacks and secure stacks; 
Rg. 11 Is a diagram illustrating detailed structure of a stack; 
Rg. 12 is a diagram illustrating a physical descn'ptor; 
s ' Rg. 13 IS a diagram Illustrating the relationship between logical pages and frames in a memory storage 
space; 

Rg, 14 is a diagram illustrating access control to objects; 

Rg. 15 is a diagram illustrating virtual processors and virtual processor swapping; 
Rg. 16 is a partial block diagram of an I/O system of the present computer system; 
w Rg. 17 is a diagram illustrating operation of a ring grant generator; 
Rg. 18 is a partial block diagram of a memory system; 

Rg. 19 is a partial block diagram of a fetch unit of the present computer system; 

Rg. 20 is a partial block diagram of an execute unit of the present computer system; 

Rg. 101 Is a more detailed partial block diagram of the present computer system; 
« Rg. 102 Is a diagram illustrating certain information structures and mechanisms of the present 
computer system; 

Rg. 103 Is a diagram illustrating process structures; 

Rg. 104 is a diagram tllusb^ting a macrostack structure; 

Rg. 105 is a diagram illustrating a secure stack structure; 
20 Rgs. 106 A, B, and C are diagrams Illustrating the addressing structure of the present computer 
system; 

Rg. 107 is a diagram illustrating addressing mechanisms of the present computer system; 
Rg. 108 is a diagram illustrating a name table entry; 

Rg. 109 is a diagram illustrating protection mechanisms of the pr^ent computer system; 
26 Rg. 110 is a diagram Illustrating instruction and microinstruction mechanism of the present computer 
system; 

Rg, 201 is a detailed block diagram of a memory system; 
Rg. 202 is a detailed block diagram of a fetch unit; 
Rg. 203 is a detailed block diagram of an ^ecute unit; 
so Rg. 204 is a detailed block diagram of an 1/0 system; 

Rg. 205 is a partial block diagram of a diagnostic processor system; 

Rg. 206 is a diagram illustrating assembly of Figs. 201—205 to form a detailed block diagram of the 
presem computer system; 

Rg. 207 is a detailed block diagram of a memory interface controller; 
35 Rg. 209 is a diagram of a memory to I/O system port Interface; 

Rg. 210 is a diagram of a memory operand port interface; 

Rg. 211 Is a diagram of a memory instruction port interface; 

Rg. 230 is a detailed block diagram of memory field interface unit logic; 

Rg. 231 is a diagram Illustrating memory format manipulation operations; 
40 Rg. 238 is a detailed block diagram of fetch unit offset multiplexer; 

Rg. 239 is a detailed block diagram of fetch unit bias logic; 

Rg. 240 is a detailed block diagram of a generalized four way, set associative cache representing name 
cache, protection cache, and address translation unit; 

Rg. 241 is a detailed block diagram of portions of computer system instmction and microinstruction 
45 control logic; 

Rg. 242 is a detailed block diagram of portions of computer system microinstruction conUol logic; 
Rg. 243 Is a detailed block diagram of further portions of computer system microinstruction control 
logic; 

Rg. 244 is a diagram illustrating computer system states of operation; 
SO Rg. 245 is a diagram illustrating computer system states of operation for a trace trap request; 

Rg. 246 is a diagram illustrating computer system states of operation for a memory repeat interrupt; 

Rg. 247 is a diagram illustrating priority level and masking of computer system events; 

Rg. 248 is a detailed block diagram of event logic. 

Rg. 249 is a detailed block diagram of microinstruction control store logic; 
S5 Rg. 251 is a diagram illustrating a return control word stack word; 

Fig. 252 is a diagram illustrating machine control words; 

Rg. 253 is a detailed block diagram of a register address generator; 

Rg. 254 is a block diagram of Interval and egg timers; 

Rg. 255 Is a detailed block diagram of execute unit control logic; 
60 Rg, 257 is a detailed block diagram of execute unit multiplier data paths and memory; 

Rg. 260 is a diagram illustrating operation of an execute unit command queue load and interface to a 

fetch unit; ^ ._ « • j -i i -c. ^ 

Rg, 261 Is a diagram illustrating operation of an execute unit operand buffer load and interface to a 

fetch unit; ^ , _ , . 

65 Rg. 262 is a diagram Illustrating operation of an execute unit storeback or transfer of results and 
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interface to a fetch unit; 

Fig. 263 is a diagram illustrating operation of an execute unit check test condition and interface to a 
fetch unit; 

Fig. 264 is a diagram illustrating operation of an execute unit exception test and interface to a fetch 
* unit: 

Ftg. 265 is a block diagram of an execute unit arithmetic operation stack mechanism; 
Rg. 266 is a diagram illustrating execute unit and fetch unit interrupt handshaking and interface; 
Rg. 267 is a diagram illustrating execute unit and fetch unit interface and operation for nested 
interrupts; 

Rg. 268 IS a diagram illustrating execute unit and fetch unit interface and operation for loading an 
execute unit control store; 

Rg. 269 is a detailed block diagram and illustration of operation of an I/O system ring grant generator; 
Rg. 270 is a detailed block diagram of a fetch unit micromachine of the present computer system; 
Rg. 271 is a diagram illustrating a logical desc^ptor; 
Rg. 272 Is a diagram Illustrating use of fetch unit stack registers; 
Rg. 273 is a diagram ilustrating structures controlling event invocations; 
Rg. 301 IS a diagram illustrating pointer formats; 
Rg. 302 Is a diagram illustrating an associated address table; 
Rg. 303 is a diagram illustrating a namespace overview of a procedure object; 
^ Rg. 304 IS a diagram illustrating name table entries; 

Rg. 305 is a diagram illustrating an example of name resolution; 
Rg. 306 is a diagram illustrating name cache entries; 

Rg. 307 is a diagram illustrating translation of SMnterpreter universal identifiers to dialect numbers; 

Rg. 401 is a diagram illustrating operating systems and system resources; 
^ Rg. 402 is a diagram illustrating multiprocess operating systems; 

Rg. 403 is a diagram illustrating an extended operating system and a kernel operating system; 

Rg. 404 Is a diagram illustrating an EOS view of objects; 

Rg. 405 is a diagram illustrating pathnames to universal identifier translation; 

Rg. 406 is a diagram illustrating universal identifier detail; 
^ Rg. 407 is a diagram Illustrating address translation with an address translation unit, a memory hash 
table, and a memory; 

Fig. 408 Is a diagram illustrating hashing In an active subject table; 

Rg. 409 Is a diagram illustrating logical allocation units and objects; 

Rg. 410 is a diagram illustrating an active logical allocation unit table and active allocation units; 
^ Rg. 411 is a diagram Illustrating a conceptual logic^ allocation unit directory structure; 
Rg. 412 Is a diagram illustrating detail of a logical allocation unit directory entry; 
Rg. 413 is a diagram illustrating universal identifiers and active object numt>ers; 
Rg. 416 is a diagram illustratir^ subject templates, primitive access control list entries, and extended 
access control list entries; 

4a Fig. 421 is a diagram illustrating an active primitive access matrix and an active primitive access matrix 
entry; 

Rg. 422 ts a diagram illustrating primitive data access checking; 

Rg. 448 is a diagram illustrating event counters and await entries; 

Rg. 449 is a diagram illustrating an await table overview; 
45 Rg. 453 is a diagram illustrating an overview of a virtual processor; 

Rg. 454 is a diagram illustrating virtual processor synchronization; 

Rg. 467 is a diagram illustrating an overview of a macrostack object; 

Fig. 468 is a diagram illustrating details of a macrostack object base; 

Rg. 469 Is a diagram Illustrating details of a macrostack frame; 
50 Rg. 470 is a diagram illustrating an overview of a secure stack; 

Rg. 471 Is a diagram illustrating details of a secure stack frame; and, 

Rg. 472 is a diagram illustrating an overview of procedure object 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
£5 The following description presents the structure and operation of a computer system incorporating a 
presently preferred embodiment of the present invention. As Indicated In the following Table of Contents, 
certain features of computer system structure and operation will first be described in en Introductory 
Overview. Next, these and other features will be described in further itetail in a more detailed Introduction 
to the detailed descriptions of the computer system. Following the Introduction, the structure and 
60 operation of the computer system will be described in detail. The detailed descriptions will present 
descriptions of the structure and operation of each of the major subsystems, or elements, of the computer 
system, of the interfaces between these major sutjsystems, and of overall computer system operation. 
Next, certain features of the operation of the individual subsystems will be presented in further detail. 
Certain convemions are used throughout the following descriptions to enhance clarity of presentation. 
65 Rrst, and with exception of the Introductory Overview, each figure referred to in the following descriptions 
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will be referred to by a three digit number. The most significant digit represents the number of the chapter 
in the following descriptions in which a particular figure is first referred to. The two least significant digits 
represent the sequential number of appearance of a figure in a particular chapter. For example, Rgure 319 
would be the nineteenth figure appearing in the third chapter. Rgures appearing in the Introductory 

^ Overview are referred to by a one or two digit number representing the order in which they are referred to 
in the Introductory Overview. It should be noted that certain figure numbers, for example. Figure 208, do 
not appear in the following figures and descriptions; the subject matter of these figures has been 
incorporated into other figures and these figures deleted^ during drafting of the following descriptions, to 
enhance clarity of presentation. 

Secondi reference numerals comprise a two digit number (00—99) preceded by the number of the 
figure in which the corresponding elements first appear. For example, reference numerals 31901 to 31999 
would refer to elenntents 1 through 99 appearing in Rg. 319. 

Rnally, interconnections between related circuitry Is r^resented in two ways. First to enhance clarity 
of presentation, interconnections between circuitry may be represented by common signal names or 

IS references, rather than by drawn representations of wires or buses. Second, where related drcuitry Is 
shown in two or more figures, the figures may share a common figure number and will be distinguished by 
a letter designation, for example. Figs. 319, 319A, and 319B. Common electrical points between such 
circuitry may be indicated by a bracket enclo^ng a lead to such a point and a de^gnation of the form 
"A— b". "A" indicates otherfigures having the same common point for example, 31 9A, and "b" designates 

20 the particular common electrical point In cases of related dnniitry shown in this manner in two or more 
figures, reference numerals to elements will be assigned in sequence through the group of figures; tfie 
figure number portion of such reference numerals will be that of the first figure of the group of figures. 

INTRODUCTORY OVERVIEW 
SS A. Hardware Overview {Hg. 1) 

B. Indh/idual Operating Features (Rgs. 2, 3, 4, 5, 6) 

1. Addr^sing (Rg. 2) 

2. S-Language Instructions and Nam^ace Addressing (Rg. 3) 

3. Architectural Base Pointer Addres^ng 
30 4. Stack Mechanisms (Rgs. 4-5) 

C. Procedure Processes and Virtual Processors (Rg. 6) 

D. OS 101 Overall Structure and Operation (Rgs. 7, 8, 9, 10, 11, 12, 13, 14, 15) 

1. Introduction (Rg.7) 

2. ComfMlers 702 (Fig. 7) 
35 3. Binder 703 (Rg. 7) 

4. EOS 704 (Rg.7) 

5. KOS and Architectural Interface 708 (Rg. 7) 

& Processes 610 and Virtual Processors 612 (Rg. 8} 
7. Processes 610 and Stacks (Fig. 9) 
40 8. Processes 61 0 and Calls (Rgs. 1 0, 1 1 ) 

9. Memory References and the Virtual Memory Management System (Rg. 12, 13} 

10. Access Control (Rg. 14) 

11, Virtual Processors and Virtual Processor Swapping (Rg. 15) 
L CS 101 Structural Implementation (Rgs. 16, 17, 18, 19, 20) 

4S 1. (lOS) 116 (Figs. 16,17) 

2. Memory (MEM) 112 (Rg. 18) 

3. Fetch Unit (FU) 120 (Rg. 19) 

4. Execute Unit (EU) 122 (Rg. 20) 

SO 1. Introduction (Rgs. 101— no) 

A General Structure and Operation (Rg. 101) 

a. General Structure 

b. General Operation 

c. Definition of Certain Terms 
^ d Multi-program Operation 

e. Multi-Language Operation 

f. Addressing Structure 

g. Protection Mechanism 

B. Computer System 10110 information Structure and Mechanisms (Rgs. 102, 103, 104, 105) 
eo a. Introduction (Rg. 102) 

b. Process Structures 10210 (Rgs. 103, 104, 105) 

1. Procedure Objects (Rg. 103) 

2. Stack Mechanisms (Figs. 104, 105) 

3. FURSM 10214 (Rg. 103) , ^^^^ 
GS C. Virtual Processor State Blocks and Virtual Process Creation (Fig. 102) 
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D. Addressing Structures 10220 {Figs. 103, 106, 107, 108) 

1. Objects, UlD's. AON's, Names, and Physical Addresses (Rg. 106) 

2. Addressing Mechanisms 10220 (Rg. 107) 

3. Name Resolution (Rgs. 103, 108) 

4. Evaluation of AON Addresses to Physical Addresses (Rg. 107) 

E. CS 10110 Protection Mechanisms (Rg. 109) 

F. CS 10110 Micro-Instruction Mechanisms (Rg. 110) 

G. Summary of Certatn CS 10110 Features and Alternate Embodinnents. 

2. Detailed Description of CS 10110 Major Subsystems Rgs. 201—206, 207—274 

A. MEM 101 1 0 {Rgs. 201, 206, 207-237) 

a. Terminology 

b. MEM 10112 physical Structure (Rg. 201) 
c- MEM 10112 General Operation 

' d. MEM 10112 Port Structure 

1. 10 Port Characteristics 

2. JO Port Characteristics 

3. Jl Port Characteristics 

a MEM 10112 ConU^ol Structure and Operation (Fig. 207) 

1. MEM 10112 Control Structure 

2. MEM 10112 Control Operation 

f. MEM 10112 Operations 

g. MEM 10112 Interfaces to JP 10114 and lOS 10116 (Rgs. 209, 210, 211, 204) 

1. 10 Port 20910 Operating Characteristics (Rgs 209, 204) 

2. JO Port 21010 Operating Characteristics (Rg. 210} 

3. Jl Port 21110 Operating Characteristics (Rg. 211) 

h. RU 20120 (Rgs. 201, 230, 231} 

B. Fetch Unit 10120 (Rgs. 202, 206, 101, 103, 104, 238) 

1. Descriptor Processor 20210 (Rgs. 202, 101, 103, 104, 238, 239). 

a Offset Processor 20218 Structure 
b. AON Processor 20216 Structure 
a Length Processor 20220 Structure 

d. Descriptor Processor 20218 Operation 

a. a. Offset Selector 20238 

b. b. Offset Multiplexer 20240 Detailed Structure (Rg, 238) 
ex. Offset Multiplexer 20240 Detailed Operation 

aaa. Internal Operation 

bbb. Operation Relative to DESP 20210 

e. Length Processor 20220 (Rg. 239) 

a. a. Length ALU ^252 

b. b. BIAS 20246 (Rg. 239) 

f. AON Processor 2021 6 
aa« AONGRF 20232 
b.b. AON Selector 20248 

2. Mentory interface 20212 (Rgs. 106, 240) 

a. a. Descriptor Trap 20256 and Data Trap 20258 

b. b« Name Cache 10226, Address Translation Unit 10228, and Protection Cache 10234 (Rg. 106) 
C.C. Structure and Operation of Generalized Cache and NC 10226 (Rg. 240) 

d.d. ATU 10228 and PC 10234 

3. Fetch Unit Control Logic 20214 (Rg. 202) 

a. a. Fetch Unit Control Logic 20214 Overall Structure 

b. b. Fetch Unit Control Logic 20214 Operation 

a. a.a. Prefetcher 20264, Instruction Buffer 20262, Parser 20264, Operation Code 

Register 20268, CPC 20270, IPC 20272, and EPC 20274 (Rg. 241) 

b. b.b. Fetch Unit Dispatch Table 11010, Execute Unit Dispatch Table 20266, and 

Operation Code Register 20268 (Rg. 242) 
ccc. Next Address Generator 24310 (Rg. 243) 
cc. FUCTL 20214 Circuitry for CS 10110 Internal Mechanisms (Rgs. 244-^0) 

a. a.a. State Logic 20294 (Rgs. 244A— 2442) 

b. b.b. Event Logic 20284 (Rgs. 245, 246, 247. 248) 
ccc Fetch Unit S-lnterpreter Table 11012 (Rg. 249) 

d.d. CS 10110 Internal Mechanism Control 

a. a.a. Return Control Word Stack 10358 (Rg. 251) 

b. b.b. Machine Control Block (Rg. 252) 

ccc Register Address Generator 20288 (Rg. 253) 



8 



EP 0 067 556 B1 



d. d.d. Timers 20296 {Fig. 254) 

e. e.e. Fetch Unrt 10120 interface to Execute Untt 10122 

C. Execute Unit 10122 (Rgs. 203, 255-268) 

a. General Structure of Execute Unit 10122 

1. Execute Unit I/O 20312 

2. Execute Unit Control Logic 20310 

3. Multiplier Logic 20314 

4. Exponent Logic 20316 

5. MumpHer Control 20318 

6. Test and Interface Logic 20320 

b. Execute Unit 10122 Operation (Rg. 255) 

1 . Execute Unit Control Logic 20310 (Rg. 255) 

a. a. Command Queue 20342 

b. b. Command Queue Event Control Store 25514 and Command Queue Event Address 

Control Store 2^16 
ac Execute Unit S-lnterpreter Table 20344 

d. d. IVIicrocode Control Decode Register 20346 

e. e. Next Address Generator 20340 

2. Operand Buffer 20322 (Rg. 256) 

3. Multiplier 20314 (Rgs. 257, 258) 

a,a. Multiplier 20314 I/O Data Paths and Memory (Rg. 257) 
a^.a. Container Size Ciieck 
b±.b. Rnal Result Output Multiplexer 20324 

4. Test and Interface Logic 20320 (Rgs, 260-268) 
a.8. RJ 10120/EU 10122 interface 

a. a-a. Loading of Command Queue 20342 (Rg. 260) 

b. b.b. Loading of Operand Buffer 20320 (Rg. 261) 
ccc, Storeback (Fig. 282) 

d, dd. Test Conditions (Rg. 263) 

e, €.e. Exception Checking (Fig. 264) 

f, f,l idle Routine 

g^.g. EU 10122 Stack Medianisms (Rgs. 265. 266, 267) 

h.h,h. Loading of Execute Unit S-lnterpreter Table M344 (Rg. 268) 

D. I/O System 101 16 (Figs, 204, 206, 269) 

a. i/0 System 101 16 Structure (Fig. 204) 

b. I/O System 10116 Operation (Rg. 269) 

1. Data Cfiannel Devices 

2. I/O Control Processor 20412 

3. Data Mover 20410 (Rg. 269) 

a. a. Input Data Buffer 20440 and Output Data Buffer 20442 

b. b. Priority Resolution and Control 20444 (Rg. 269) 

E. Diagnostic Processor 10118 (Rg. 101, 205) 

F. CS 10110 Micromachine Structure and Operation (Rgs. 270—274) 

a. Introduction 

b. Overview of Devices Comprising FU Micromachine (Rg. 270) 

1. Devices Used By Most Microcode 

a. a. MOD Bus 10144, JPD Bus 10142, and DB Bus 27021 

b. b. Microcode Addressing 

c. c. Descriptor Processor 20218 (Rg. 271) 

d. d. EU 10122 Interface 

2. Specialoed Micromachine Devices 

a. a. Instruction Stream Reader 27001 

b. b. SOP Decoder 27003 

ac. Name Translation Unit 27015 

d. d. Memory fieferenoe Unit 27017 

e. e. Protection Unit 27019 

f. f. KOS Micromachine Devices 

c. Micromachine Stacks and Microroutine Calls and Returns (Rgs. 272, 273) 

1. Micromachine Slacks (Rg. 272) 

2. Micromachine Invocations and Returns 

3. Means of Invoking Microroutines 

4. Occurrence of Event Invocations (Rg. 273) 

d. Virtual Mlcromachines and Monitor Micromachine 

1. Virtual Mode 

2. Monitor Micromachine 
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e. Interrupt and Fault Handling 

1. General Prindpfes 

2. Hardware Interrupt and Fault Handling in CS 10110 

3. Monitor Mode: Differential Masking and Hardware Interrupt Handling 
^ ' g. FU Micromachine and CS 10110 Subsystems 

3. Name^ace, S-lnterpreters and Pointers (Figs. 301—307, '274) 

A. Pbinters and Pointer Resolution (Figs. 301« 302) 
& Pointer Formats (Rg. 301) 

b- Pointers In FU 10120 (Rg. 302) 
c Descriptor to Pointer Conversion 

B. Namespace and the S-lnterpreters {Rgs. 303—307) 

a. Procedure Object 606 Over>4ew (Rg. 303) 

b. Namespace 

1. Name Resolution and Evaluation 

2. The Name Table (Rg. 304) 

3. Architectural Base Pointers (Rgs. 305, 306) 

a. a. Resolving and Evaluating Names (Rg. 305) 

b. b. Implementation of Name Evaluation and Name Resolve in CS 10110 
ex. Name Cache 10226 Entries (Rg. 30Q) 

d. d. Name Cache 10226 Hits 

e. e. Name Cache 10226 Misses 
f.f. Rushing Name Cache 10226 

g.g. Fetching the Instruction Stream 
^ h.h. Parsing the Instruction Stream 

c The S-lnterpreters (Rg. 307) 

1. Translating SIP into a Dialect Number (Rg. 307) 

2. Dispatching 

4. The Kernel Operation System 

A. introduction 

a. Operating Systems (Rg. 401) 

1. Resources Controll^ by Operating Systems (Rg. 402) 

b. The Operating System in CS 10110 

^ c. Extended Operating System and the Kernel Operating System (Rg. 403) 

B. Objects and Object Management (Rg. 404) 

a. Objects and User Programs (Rg. 405) 

b. UIDs 40401 (Rg. 406) 

c. Object Attributes 

^ d. Attributes and Access Control 

e. Implementation of Objects 

1. Introduction (Rgs 407, 408) 

2. Objects in Secondary Storage 10124 (Rgs. 409, 410). 

a.a. Representation of an Object's Contents on Secondary Storage 10124 
4S hJx LAUD 40903 (Rgs. 41 1, 412) 

a Active Objects (Rg. 413) 
a^. UID 40401 to AON 41304 Translation 

C. The Access Control System 
a. Subjects 

so b. Domains 

c Access Control Lists 

1. Subject Templates (Rg. 416) 

2. Primitive Access Control Lists (PACLs) 

3. APAM 10918 and Protection Cache 10234 (Rg. 421} 

X 4. Protection Cache 10234 and Protection Checking (Rg. 422) 

D. Processes 

1. Synchronization of Processes 610 and Virtual Processors 612 

a. Event Counters 44801, Await Entries 44804, and Await Tables (Rg. 448, 449) 

b. Synchronization with Event Counters 44801 and Await Entries 44804 
a E. Virtual processors 612 (Rg. 453) 

a. Virtual Processor Management (Rg. 453) 

b. Virtual Processors 612 and Synchronization (Fig. 454) 
F. Process 610 Stack Manipulation 

1. introduction to Call and Return 
fiS 2. Macrostacks (MAS) 502 (Rg. 467) 
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3^ MAS Base 10410 (Fig. 468) 

b.b. Per-domain Data Area 46853 (Rg. 468) 

cc. MAS Frame 46709 D^sll (Fig. 469) 

3. SS 504 (Rg. 470) 

a. 8. SS Base 47001 (Hg. 471) 

b. b. SS Frames 47003 (Rg. 471 ) 

a. a.a. Ordinary SS Frame Headers 10514 (Hg. 471) 

b. b.b. Detailed Structure of Macrostate 10516 (Fig. 471) 
C.C.C. CrossKlomain SS Frames 47039 (Rg. 471 ) 

4. Portions of Procedure Object 608 Relevant to Call and Return (Rg. 472) 

5. Execution of Mediated Calls 

a. a. Mediated Call SIIMs 

b. b. Simple Mediated Calls (Rgs. 270, 468, 4®, 470, 471, 472) 

cc. Invocations of Procedures 602 Requiring SEBs 4«64 (Rgs. 270, 468. 469, 470,471. 472) 
w d.d. Cross-Procedure Object Calls (Figs. 270, 468, 469, 470, 471, 472) 

e.e. Cross-Domain Calls (Rgs. 270, 408, 418, 468, 469. 470. 471, 472) 
if. Failed Cross-IDomain Calls (Rgs. 270, 468, 469. 470, 471, 472) 
& Neighborhood Calls (Rgs. 468. 469, 472) 

20 

INTRODUCTORY OVERVIEW 
The following overviews will first briefly describe the overall physical structure and operation of a 
presently preferred embodiment of a digital computer system incorporating the prraent In^^'rt'O'^,™" 
rartain operating features of that computer system will be Individualiy described. Next overall operation of 
25 computer system will be described in terms of those individud features. 

^ "Rrf^rring to pS-Tabl^ diagram of Computer System (CS) 101 incoiporating the prraent Invention is 
shoym- Sr elements of CS 101 are UO System (IDS) 116, Memory (MEM) 112. and Job Processor gP) 
30 114^ m fs »^ri^ of a Fetch Unit (FU) 120 and an Execute Unit (EU) 122. CS 101 may also Include a 
Diagnostic Processor (DP), not shown or described in the instant description. . i«n««.n 

Referring first to lOS 1 16, a primary function of lOS 1 16 is control of transfer of 
MEMTSthToutsldeworid. UTfonmtion is transferred from MEM 112tD 10^ 

and from lOS 116to MEM 112 through MIO Bus 129. lOMC Bus 131 is comprised of ^-tBiwilona" ""tro' 

35 signals coordinating operation of MEM 112 and lOS 116. lOS 116 also has '/'^f '^^J" "^i^O djrough 
laiP Bus 132. lOJP Bus 132 is a bi-directional control bus comprised essentially of two intemjpt lines. 
These interrupt lines allow FU 120 to indicate to lOS 116 that a request for infom>ation by FU 120 h» been 
placed in MEM 112. and allows lOS 116 to inform FU 120 that information requeued by FU 120 has been 
fransferred into a location in MEM 112. MEM 112 Is CS 101's main memory and serves as ttie path for 

« information transfer between the outside worid and JP 1 14. MEM 1 12 provides instmcbons and data to FU 
120 and EU 122 through Memory Output Data (MOD) Bus 140 and receives information from RJ 120 ami EIJ 
122 through Job Processor Data (JPD) Bus 142. FU 120 submits read and write requests to MEM 112 
flirough Physical Descriptor (PD) Bus 146. . r 

JP 1 14 is CS 101 's CPU and, as described above, is comprised of FU 120 and EU 1 22. A primary function 

« of FU 120 is executing operations of user's programs. As part «rf this function, "^^ "1™' V/^FU^^ M 
Instructions and data from MEIW 112 and transfer of results of JP 114 operations back to MEM 112. FU 120 
also performs operating system type functions, and is capable of operating as a conriplete, seneral purpwe 
CPU. EU 122 is primarily an arithmetic and logic unit provided to relieve FU 120 of certain anthmehc 
operations. FU 120, however. Is capable of performing EU 122 operations. In alternate emboc^n^^ 

so 101, EU 122 may be provided only as an option for users having P*"*"; sr arithmebc requiremer^tt. 
Coordination of FU 120 and EU 122 operations is accomplished through FU/EU (FUEU Bus 148, which 
includes bWirectional control signals and mutual Interrupt lines. As descnbed fijrther below. l»thKn2^ 
and EU 122 contain register file an^ys refenwl to respectively as CRF end ERF. m addition to registers 
assoNated with, for example, ALUs. ^ . 

» A primary feature of CS 101 is that lOS 116. MEM 1 12, FU 120 and EU 122 each contain separate and 
independ^t microinstruction control, so tiwt lOS 116. MEM 112, and EU 122 
undeVtiie general control of FU 120. EU 122. for example, may execute a complex anthmobc operation 
upon receipt of date and a single, initial command from FU 120. ,„„,„^ ^ r<i ini »riii 

Having brieHy described tfie overall stmcture and operation of CS 101, certain features of CS 101 vinll 

eo be individually furtiisr described next below. 

B. Individual Operating Features (Rgs. 2, 3, 4, 5. 6) 

^' R^elringto R^la diagramic reprosentation of portions of CS 101's addressing sfructure » shown. 
65 CS lOI's addressing structure is based upon tiie concept of Objects. An Object may be regarded as a 
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container for holding a particular type of information. For axampte, one type of Object may contain data 
v^ile another type of Object may contain Instructions or procedures, such as a user program. Still another 
type of Ol^act may contain microcode. In general, a particular Object may contain only one type or class of 
Information. An Object may« for example, contain up to 232 bits of informationi but the actual size of a 
^ particular Object is flexible. That is, the actual size of a particular Object will increase as information is 
written into that Object and will decrease as information is taken from that Object. In general. Information 
in Objects is stored sequentially, that is without gaps. 

Each Object which can ever exist in. any CS 101 system is uniquely idemified by a serial number 
referred to as a Unique Identffier (UID). A DID is a 128 bit value comprised of a serial number dependent 
upon, for example, the particular CS 101 system and user, and a time code indicating time of creation of 
that Object UIC^ are permanently assigned to CX>jects, no two Objects may have the same UID, and UIDs 
may not be reused. UIDs provide an addressing base common to all CS 101 systents which may ever exist 
through which any Object ever created may be permanently and uniquely identified. 

As described above, UIDs are 128 bit values and are thus larger than may be conveniently handled in 
fS present embodiments of CS 101. In each CS 101, therefore, those Objects which are active (currently being 
used) in that system are assigned 14 bit Active Object Numbers (AOIMs). Each Object active in that systerrf 
will have a unique AON. Unlike UIDs, AONs are only temporarily assigned to particular Objects. AONs are 
valid only within a particular CS 101 and are not unique between systems. An Object need not physically 
reside in a system to be assigned an AON, but can be acth^e in that system only if it has k^en assigned an 
20 AON. 

A particular bit within a particular Object may be identified by means of a UID address or an AON 
address. In CS 101, AONs and AON addresses are valid only within JP 114 while UIDs and UID addresses 
are used in MEM 112 and elsewhere. UID and AON addresses are formed by appending a 32 bit Offset (0) 
field to that Object's UID or AON. O fields indicate offset, or location, of a particular bit relative to the start of 
^ a particular Object 

Segments of information {sequences of information bits) witiiln particular Objects may be identified by 
means of descriptors. A UID descriptor is formed by appending a 32 bit Length (L) field of a UID address. An 
AON, or logical descriptor is forrrved by appending a 32 bit Lfi^d to an AON address. L fields identify length 
of a segment of information bits v\rtthin an Object starting from the information bit identified by the UID or 

30 AON address. In addition to length information, UID and logical descriptors also contain Type fields 
containing information regarding certain characteristics of the information in the Information segment 
Again, AON based descriptors are used wthin JP 114, while UID based descriptors are used In MEM 112- 
Referring to Rgs. 1 and 2 together, translation between UID addresses and descriptors and AON 
addresses and descriptors is performed at the interface between MEM 112 and JP 114. That is, addresses 

35 and descriptors within JP 1 14 are in AON form while addresses and descriptors in MEM 1 12, lOS 116, and 
the external worid are in UID form. In other embodiments of CS 101 using AONs. transformation from UID 
to AON addressing may occur at other interfaces, for example at the tOS 1 1 6 to MEM 112 interface, or at the 
lOS 1 1 6 to external worid interface. Other embodiments of CS 1 01 may use UIDs throughout, that is not use 
AONs even in JP 114. 

40 Rnally, Information within MEM 112 is located through MEM 112 Physical Addresses Identifying 

particular physical locations within MEM 112's memory space. Both lOS 116 and JP 114 address 
Infomnation within MEM 112 by providing physical addresses to MEM 112, In the case of phyacat 
addresses provided by JP 1 14, these addresses are referred to as Physical Descriptors (PDs). As described 
below, JP 114 contains circuitry to translate logical descriptors into physical descriptors. 

2. S-Language Instructions and Namespace Addressing (Fig. 3) 

CS 101 is both an S-Language machine and a Namespace machine. That is, operations to be executed 
by CS 101 are expressed as S-Language Operations (SO^) while operands are identified by Names. SOPs 
are of a lower, more detailed, level than user language instructions, for example FORTRAN and C060U but 

so of a higher level than conventional machine language lnstnK:tions. SOPd are specific to particular user 
languages rather than a particular embodiment of CS 101, while conventional machine language 
instructions are specific to particular machines. SOPs are in turn interpreted and executed by microcode. 
There will be an S-Language Dialect, a set of SOPs, for each user languages. CS 101, for example, may have 
SOP Dialects for COBOL, FORTRAN, and SPL A particular distinction of CS 101 is that ail SOPs are of a 

55 uniform, fixed length, for example 1 6 bits. CS 1 01 may generally contain one or more sets of miaocode for 
each S-Language Dialect These microcode Dialect Sets may be completely distinct or may overiap where 
more than one SOP utilizes the same microcode. 

As stated above, in CS 101 all operands are identified by Names, which are 8, 12, or 16 bit numbers, CS 
101 includes one or more "Name Tables" containing an Entry for each operand Name appearing in 

60 programs currentiy being executed. Each Name Table Entry contains Information describing the operand 
referred to by a particular Name, and the directions necessary for CS 101 to translate that information into a 
corresponding logical descriptor. As previously described, logical descriptors may then be transformed 
into physical descriptors to read and write operands from or to MEM 112. As described above, UIDs are 
unique for all CS 101 systems and AONs are unique within individual CS 101 systems. Nam^, however, are 

C5 unique only within the context of a user's program. That is, a particular Name may appear in two different 
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user's programs and, within each program, wiii have different Name Table Entries and will refer to different 

operands.^ may thereby be considered as utilizing two sets of Instructions. Afirst set is comprised of SOPs, 
that is Instructions selecting algorithms to be executed. The second set of Instructions are comprised ot 
^ Names, which may be regarded as entry points Into tables of instructions for making references regarding 

operands. * • i ciw ■ 

Referring to Fig. 3, a dlagramic representation of CS 101 Insiruction stream Is shown. A typical sin is 
comprised of an SOP and may Include one or more Names referring to operands. SOPs and Names allow 
user's programs to be expressed in very compact code. Fewer SOPs than machine language instructions 
are required to express a user's program. Also, use of SOPs allows easier and simple- construction off 
compilers, and facilitates adaption of CS 101 systems to new user languages. In addition, use of Names to 
refer to operands means that SOPs are independent of the form of the operands upon which they operate. 
This in tum allows for more compact code In expressing user programs in that SOPs specifying operations 
dependent upon operand form are not required. 

IS 

3. Archrtec^ral Base Pointer Addressing 

As will be descnbed further below, a user's program residing In CS 101 will include one or more 
Objects. Rrst, a Procedure Object contains at least the SINs of the user's programs and a Name Table 
containing entries for operand Names of the program. The SINs may include references, or calls, to other 

2^ Procedure Objects containing, for example, procedures available in common to many users. Second, a 
Static Data Area may contain static data, that is data having an existence for at least a single execution of 
the program. And third, a IVlacro-stack, described below, may contain local data, that is data generated 
during execution of a program. Each Procedure Object, the Static Data Area and the Macn>-stack are 
individual Objects identified by UlDs and AONs and addressable through UIO and AON addresses an 

^ descriptors. 

Locations of information within a user's Pnwedure Objects, Static Data Area, and Macro-stack are 
. expressed as offsets from one of three values, or base addresses, referred to as Architectural Base Pointers 
(ABPs). For example, location information in Name Tables Is expressed as offsets from one of the ABPs. 
ABPs may be express«i as previously described. . ^ . n 

30 The three ABPs are the Frame Pointer (FP), the Procedure Base Pointer (PBP), and the Static Data 
Pointer (SDP). l-ocations of data local to a procedure, for example in the procedure's Macrostack, are 
described as offsets from FP. Locations of non-local data, that is Static Data, are described as offsets from 
SDP. Locations of SINs in Procedure Objects are expressed as offsets from PBP; these offsets are 
determined as a Program Counter (PC) value. Values of the ABPs vary during program execution and are 

35 therefore not provided by the corrrpiler converting a user's high level language program into a program to 
be executed in a CS 1 01 system.- When the program is executed, CS 1 01 provides the proper valu^ for the 
ABPs. When a program Is actually being executed, the ASF's values are stored in FU 120*3 GRF. 

Other pointers are used, for example, to identiiFy the top frame of CS 101's Secure Stack (a microcode 
level stack described below) or to identify the microcode Dialect cunrentiy being used In mecute the SINs of 

^ a procedure. These pointers are similar to FP, SDP, and PBP. 

4. Stack Mechanisms (Rg. 4—5) ^ , . . 

Referring to Rg. 4 and 4A. diagramic representations of various control levels and stack mechanisms 
of. respectively, conventional machines and CS 101, are shown. Referring first to Rg. 4, top level of control 

4ff is provided by User Unguage Instructions 402, for example in FORTRAN or COBOL. User Unguage 
Instructions 402 are converted into a greater number of more detailed Machine Language Instructions 404, 
used within a machine to execute user's programs. Within tfie machine. Machine Language Instructions 
404 are interpreted and executed by Microcode Instructions 406, that is sequences of microinstructions 
which in tum directiy control Machine Hardware 408. Some conventional machines may include a Stack 

SO Mechanism 410 used to save current machine stete, that is current microinstruction and contents of various 
machine registers, if a current Machine Language Instnjction 404 cannot be executed or is interrupted. In 
general machine state on the microcode and hardware level is not saved. Execution of a current Machine 
Language Instruction 404 is later resumed at stert of the microinstruction sequence for executing that 
Machine Language Instruction 404. 

S5 Referring to Fig. 4A, top level control In CS 101 is by User Language Instructions 412 as in a 
conventional machine. In CS 101, however. User Language Instructions 412 are translated Into SOPs 414 
which are of a higher level than conventional machine language instructions. In general, a »ngle User 
Language instruction 412 is transformed into at most two or three SOPs 414, as opposed to an entire 
sequence of conventional Machine Language Instructions 404. SOPs 414 are interpreted and executed by 

€0 Microcode Instructions 416 (sequences of microinstructions) which directly control CS 101 Hardware 418. 
CS 101 Includes a Macro-stack Mechanism <MAS) 420, at SOPs 414 level, virtiich is comparable to but 
different in construction and operation from a conventional Machine Language Stack Mechanism 410. CS 
101 also includes Micro-code Stock Mechanisms 422 operating at Microcode 416 level, so that execution of 
an interrupted microinstmction of a microinstruction sequence may be later resumed with the particular 

65 microinstmction which was active at the time of the interrupt. CS 101 is therefore more efficient in handling 
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fnterrupts in that execution of microlnstructton sequences is resumed from the particular point that a 
microinstruction sequence was interrupted, rather from the beginning of that sequence. As will be 
described further below, CS lOVs Micro-code Stack IVIechanisms 422 on microcode level is effectively 
comprised of tvra stack mechanisms. The first stack is Micro-Instruction Stac* (MIS) 424 while the second 
* stack is referred to as Monitor Stack (MOS) 426. CS 101 SIN Microcode 428 and MIS 424 are primarily 
concerned with execution of SOPs of user's programs. Monitor Microcode 430 and MOS 426 are concerned 
with operation of certain CS 101 internal functions. 

CKvision of CS lOI's microcode stacks into an MIS 424 and a MOS 426 Illustrates a further feature of CS 
101. In conventional machines, monitor functions may be performed by a separate CPU operating in 
conjunction with the machine's primary CPU. In CS 101, a single hardware CPU is used to perform both 
functions with actual execution of both functions performed by separate groups of microcode. Monitor 
microcode operations may be initiated either by certain SlNs 414 or ksy control signals generated directly by 
CS lOVs Hardware 4ia Invocation of Monitor Microcode 430 by Hardware 418 generated signals insures 
that CS 101 's monitor functions may always be invoked. 

Referring to Rg. 5, a dfagramic representation of CS 101,s stack mechanisms for a single user's 
program, or procedure, is shown. Basically, and with exception of MOS 426, CS 101's stacks reside in MEM 
112 with certain portions of those stacks accelerated Into FU 120 and £U 122 to enhance speed of operation. 

Certain areas of MEM 112 storage space are set aside to contain Macro-Stacks (MASs) 502, stack 
medianisms operating on the SINs level, as described abova Other areas of MEM 112 are set aside to 
20 contain Secure Stack (SS) 504, operating on the microcode level, as described above and of which MIS 424 
is a parL 

As described further below, both FU 120 and EU 122 contain registerfile aoays, referred to respectively 
as GRF and ERF« in addition to registers associated with, for example, ALUs. Referring to FU 120, shov\m 
therein is FU 120*8 GRF 506. GRF 506 is horizontally divided Into three areas. A first area, referred to as 

^ General Registers (GFis) 508 may In general be used in the same manner as registers In a conventional 
machine. A second area of GRF 506 is Micro-Stack (MIS) 424, and is set aside to contain a portion of a 
Process's SS 504. A third portion of GRF 506 is set aside to contain MOS 426. Also indicated in FU 120 is a 
block referred to as Microcode Control Stats (mCS) 510. mCS 510 represents registers and other FU 120 
hardware containing current operating state of FU 120 on the microinstruction and hardware level. mCS 

^ 510 may include, for example, the current microinstruction controlling operation of FU 120. 

Referring to EU 122, indicated therein is a first block referred to as Execute Unit State (EUS) 512 and a 
second block referred to as SOP Stack 514. EUS 512 is similar to mCS 510 in FU 120 and includes ail 
ragisters and other EU 122 hardware containing information reflecting £U 122's current operating state. 
SOP Stack 518 is a portion of EU 122's ERF 516 which has been set aside as a stack mechanic to contain a 

^ portion of a process's SS 504 pertaining to EU 122 operations. 

Considering first MASs 502, as stated above MASs 502 operate generally upon the SINs level. MASs 
502 are used In general to store current state of a processes (defined below) execution of a user's program. 

Referring next to MIS 424, in a present embodiment of CS 101 that portion of GRF 506 set aside to 
contain MIS 424 may have a capacity of eight stack frames. That is, up to 8 microinstruction level interrupts 

40 or calls pertaining to execution of a user's program may be stacked within MIS 424. Information stored In 
MIS 424 stack frames is generally information from GR 508 and MCS 510. MIS 424 stack frames are 
transferred between MIS 424 and SS 504 such that at least one frame, and no more than 8 frames, of SS 504 
re^de In GRF 506. This insures that at least the top-most frames of a proce^'s SS 504 are present in FU 1 20, 
thereby enhancing speed of operation of FU 120 by providing rapid access to those top frames. SS 504, 

45 residing in MEM 112, may contain, for all practical purposes, an unlimited number of frames so that MIS 
424 and SS 504 appear to a user to be effectively an infinitely deep stack. 

MOS 426 resides entirely in FU 120 and, in a present embodiment of CS 101, may have a capadty of 8 
stack frames. A feature of CS 101 operation is that CS 101 mechanisms for handling certain events or 
interrupts ^ould not rely in its operation upon those portions of CS 101 whose operation has resulted in 

so those faults or interrupts. Among events handled by CS 101 monitor microcode, for example, are MEM 112 
page faults. An MEM 112 page fault occurs whenever FU 120 makes a reference to data in MEM 112 and 
that data is not in MEM 1 1 2. Due to this and similar operations, MOS 426 resides entirely in FU 120 and thus 
does not rely upon information in MEM 112. 

As described above, GRs 508, MIS 424, and MOS 426 each reside in certain assigned portions of GRF 

55 B06, This allows flexibility in modifying the capacity of GRs 508, MIS 424, and MOS 426 as indicated by 
experience, or to modify an individual CS 101 for particular purposes. 

Referring finally to EU 122, EUS 512 is functionally a part of a process's SS 504. Also as previously 
described, EU 122 performs arilhmetic operations in response to SINs and may be interrupted by FU 120 to 
aid certain FU 120 operations. EUS 512 allows stacking of interrupts. For example, FU 120 may first 

60 interrupt an arithmetic SOP to request EU 122 to aid in evaluation of a Name Table Entry. Before that first 
interrupt is completed, FU 120 may interrupt again, and so on. 

SOP Stack 514, is a single frame stack for storing current state of EU 122 when an interrupt interrupts 
execution of an arithmetic SOP. An interrupted SOP's state is transferred into SOP Stack S14 and the 
Interrupt begins execution in EUS 512. Upon occurrence of a second interrupt (before the first interrupt is 

SS completed) EU's first interrupt state la transferred from EUS 512 to a stack frame in SS 504, and execution 
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of the second interrupt begins in EUS 51 2. ff a third interrupt occurs before completion of second interrupt 
EU's second interrupt state is transferred from EUS 512 to another stack frame in SS 504 and execution of 
the third interrupt is begun in EUS 512; and so on. EUS 512 and SS 504 thus provide an apparently infinitely 
deep microstack for EU 122. Assuming that the third interrupt Is completed, state of second Interrupt is 
transferred from SS 504 to EUS 512 and execution of second Interrupt resumed. Upon completion of 
second interrupt state of first Interrupt is transferred from SS 504 to EUS 512 and completed. After 
completion of first interrupt state of the original SOP Is transferred from SOP Stack 514 to EUS 512 and 
execution of that SOP resumed. 

C Procedure Processes, and Virtual Processors (Rg. 6) 

Referring to Fig. 6, a diagramic representation of procedures, processes, and virtual processes is 
shown. As described above, a user's program to be executed is compiled to result in a Procedure 602. A 
Procedure 602 includes a User's Procedure Object 604 containing the SOPs of the user's program and a 
Name Table containing Entries for operand Names of the user's program, and a Static Data Area 606. A 
Procedure 602 may also include other Procedure Objects 608, for example utility programs available in 
common to many users. In effect a Procedure 602 contains tiie instructions (procedures) and data of a 
user's program* 

A Process 610 includes, as described above, a Macro Stack (ly^S) 502 storing state of execution of a 
user's Procedure e02 at the SOP level, and a Secure Stack (SS) 504 storing state of execution of a user's 
Procedure 602 at the microcode level. A Process 610 is associated with a user's Procedure 602 through the 
ABPs described above and which are stored in the MAS 602 of the Process 610. SimUarty, the MAS 502 and 
SS 504 of a Process 610 are associated through non-architectural pcunters, described above. A Process 602 
is effectively a body of information linking the resources, hardware, microcode, and software* of CS 101 to 
a user's Procedure 602. in effect a Process 610 makes the resources of CS 101 available to a useKs 
Procedure 602 for executing of that Procedure 602. CS 101 is a multi-program machine capable of 
accommodating up to, for example, 128 processes 610 concurrently. The number of Process^ 610 which 
may be executed concurrently Is detenmined by the number of Virtual Processors 612 of CS 101. There may 
be, for example, up to 16 Virtual Processors 612. 

As indicated in Fig. 6, a Virtual Processor 612 is comprised of a Virtual Processor State Block (VPSB) 614 
associated with the SS 504 of a Process 612. A VPSB 614 is, in effect a body of Information accessible to CS 
lOVs operating system and through which CS lOI's operating system is infomied of, and provided with 
access to, a Proc^ 610 through that process 610*8 SS 504. A VPSB 614 is associated with a pardcular 
Process 610 by writing Infbmnatlon reganSng that Process 610 into tiiat VPSB 614. CS 101's operating 
system may, by gaining access to a Process 610 through an associated PSB 614, read Information, such as 
ASP'S, from that Process 610 to FU 120, thereby ewaj^ng that Process 610 onto FU 120 for execution. It is 
said ^at a Virtual Processor 612 thereby executes a process 610; a Virtual Processor 612 may be regarded 
therefor, as a processor having "Virtual", or potential, existence which becomes ''real" when its associated 
Process 610 is swapped into FU 120. In CS 101, as Indicated in Rg. 6, only one Virtual Processor 612 may 
execute on FU 120 at a time and the operating system selects which Virtual Processor 612 v»il excecute on 
FU 120 at any gWen time. In addition, CS 101's operating system selects which Processes 610 will be 
assodated with the available Virtual Processors 612. 

hiaving briefly described certain individual structural and operating features of CS 101, die overall 
operation of CS 101 will be described in further detail next below in terms of these individual features. 

D. CS 101 Overall Structure and Operation (Rgs. 7, 8, 9, 10, 11, 12, 13, 14, 15) 
1. Introduction (Rg. 7) 

As indicated in Rg. 7, CS 101 is a multiple level system wherein operations in one level are generally 
transparent to higher levels. User 701 does not see the S-Language, addressing, and protection 
mechanisms defined at Architectural Level 708. Instead, he sees User Interface 709, which is defined by 
Compilers 702, Binder 703, and Extended (high level ) Operating System (EOS) 704. Compilers 702 translate 
high-level language code into SINs and Binder 703 translates symbolic Names in programs into UID-offoet 
addresses. 

As Rg. 7 shows. Architectural Level 708 is not defined by FU 120 Interface 711. Instead, the 
architectural resources level are created by S-Language Interpreted SINs when a program is executed; 
Name Interpreter 715 operates under control of S-Language Interpreters 705 and translates Names into 
logical descriptors. In CS 101, both S-Language Interpreters 705 and Name Interpreter 715 are implemented 
as microcode which executes on FU 120. S-Language Interpreters 705 may also use EU 122 to perform 
calculations. A Kernel Operating System (KOS| provides CS 101 with UID-offset addressing, objects, access 
checking, processes, and virtual processors, described further below. KOS has three kinds of components: 
KOS Microcode 710, KOS Software 706, and KOS Tables in MEM 112 KOS 710 components are microcode 
routines which assist FU 120 in performing certain required operations. Like other high-level language 
routines, KOS 706 components contain SINs which are interpreted by S-lnterpreter Microcode 705. Many 
KOS High-Level Language Routines 706 are executed by special KOS processes; others may be executed 
by any process. Both KOS High-Level Language Routines 706 and KOS Microcode 710 manipulate KOS 
Tables in MEM 112. 
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FU 120 Interface 71 1 is visible only to KOS and to S-lnterpreter Microcode 705. For the purposes of this 
discussion, FU 120 may be seen as a processor which contains the following nriain elements: 

A Control Mechanism 725 which executes microcode stored In Writable Control Store 713 and 
manipulates FU 120 devices as directed by this microcode. 

A GRF 506 containing registers in which data may be stored. 

A Processing Unit 715. 

All microcode which executes on FU 120 uses these devices; there is in addition a group of devices for 
performing special functions; these devices are used only by microcode connected with those functions. 
The microcode, the spedaltzed devices, and sometimes tables in MEM 112 make up logical machines for 
performing certain functions. These machines will t>e descnbed in detail below. 

In the following, each of the levels illustrated in Rg. 7 will be discussed in turn. Rrst the components at 
User Interfece 709 will be examined to see how they translate user programs and requests into fomds 
usable by CS 101. Then the components below the User Interface 709'will be examined to see how they 
create logical machines for performing CS 101 operations. 

2. Compilers 702 (Rg. 7) 

Compilers 702 translate files containing the highievel language code written by User 701 into 
Procedure Objects 608. Two components of a Procedure Object 608 are code (SOPs) and Names, previously 
described. SOPs represent operations, and the Nam^ represent data. A single SIN thus specifies an 
operation to be performed on the data represented by the Names. 

3. Binder 703 {Rg. 7} 

In Sonne cases. Compiler 702 cannot define locations as offsets from an ABP. For example, if a 
procedure calls a procedure contained in another procedure objert, the location to which the call transfers 
control cannot be defined as an offset from the PEP used by the calling procedure. In these cases, the 
compiler uses symbolic Names to define the locations. Binder 703 Is a utility which translates symbolic 
Names into UID-offset addresses. It does so in two ways: by combining separate f*rocedure Objects 608 
into a single large Procedure Object 608, and then redefining symbolic Names as offsets from that 
Procedure Object 608's ABPs, or by translating symbolic Names when the program is executed. In the 
second case. Binder 703 requires assistance from EOS 704. 

4. EOS 704 (Rg. 7) 

EOS 704 manages the resources that User 701 requires to execute his programs. From User 701 's point 
of view, the most important of these resources are files and processes. EOS 704 creates files by requesting 
KOS to create an object arwi then mapping the file onto the object When a User 701 performs an operation 
on a file, EOS 704 translates the file operation irto an operation on an ot)ject. KOS creates them at EOS 
704's request and mates them available to EOS 704, which In turn makes them available to User 701 . EOS 
704 causes a process to execute by associating it a Virtual Processor 612. In logical terms, a Virtual 
Processor 612 is ^e means which KOS provides EOS 704 for executing processes 610, As many Processes 
610 may apparently execute simultaneously in CS 101 as there are Virtual Processors 612, The illusion of 
simultaneous execution is created by multiplexing JP 114 among the Virtual processors: the manner in 
which Processes 610 and Virtual Processors 610 are implemented will be explained in detail below. 

5. KOS and Architectural Interface 708 (Rg. 7) 

S-Interpreter Microcode 710 and Name interpreter Microcode 715 require an environment provided by 
KOS Microcode 710 and KOS Software 706 to execute SINs. i=br example, as previously explained. Names 
and program locations are defined In terms of ABPs whose values vary during execution of the program. 
The KOS environment provides values for the ABPs. and therefore makes K possible to interpret Names 
and program locations as locations in MEM 112. Similarly, KOS help is required to transfomn logical 
descriptors into references to MEM 112 and to perform protection checks. 
The environment provided by KOS has the following elements: 
A Process 610 which contains the state of an execution of the program for a given User 701. 
A Virtual Processor 612 which gives the Process 610 access to JP 114. 

An Obje<^ Management System which translates UIDs into values that are usable inside JP 114. 
A Protection System which checks whether a Process 610 has the right to perform an operation on an 
Object 

A Virtual Memory Management System which moves those portions of Objects which a Process 610 
actually references from the outside worid Into MEM 112 and translates logical descriptors into physical 
descriptors. 

In the following, the logical properties of this environment and the manner in which a program is 
executed in it will be explained. 

6. Processes 610 and Virtual Processors 612 (Rg. 8) 

Processes 610 and Virtual Processors 612 have already been described in logical terms; Rg. 8 gives a 
high-level view of their physical implementation. 
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Rg. 8 illustrates the relationship between Processes 610, Virtual Processors 612, and JP 114. In physical 
terms, a Process 610 is an area of MEM 112 which contains the current state of a user's execution of a 
progrann. One example of such state is the current values of the ABPs and a program Counter (PC). Given 
the current value of the PBP and the PC, the next SOP in the program can be executed; similarly, given the 
current values of SDP and PP. the program's Names can be correctly resolved. Since the Process 610 
contains the current state of a program's execution, the program's physical execution can be stopped and 
resumed at any point. It is thus possible to control program execution by means of the Process 610, 

As already mentioned, a process 610's execution proceeds only when KOS has bound it to a Virtual 
Processor 612, that Is, an area of MEM 112 containing the state required to execute microinstructions on JP 
1 14 hardware. The operation of binding is simply a transfer of Process 61 0 state from the Process 61 0's area 
of MEM 1 12 to a Virtual Processor 612^3 area of MEM 1 12. Since binding and unbinding may take place at 
any time* EOS 704 may multiplex Processes 610 among Virtual Processors 612. In Rg. 8, there are more 
Processes 610 than there are Virtual Processors 612. The physical execution of a Process 610 on JP 114 
takes place only while the Process 610's Virtual Processor 612 is bound to JP 114, i.e., when state is 
transferred from Virtual Processor 61 2's area of MEM 112toJP114's registers. Just as EOS 704 muKiplexes 
Virtual Processors 612 among Processes 610, KOS multiplexes JP 1 14 among Virtual Processors 612. in Rg. 
8, only one Process 610 is being physically executed. The means by which JP 114 Is multiplexed among 
Virtual Processors 612 will be descdl^ed in further detail below. 

7. Processes 610 and Stacks (Fig. 9( 

In CS 101 systems, a Process 610 is made up of 8b( Objects: one Process Object 901 and Rve Stack 
Object 902 to 906. Hg. 9 illustrates a Process 610. Process Object 901 contains the information which EOS 
704 requires to manage the Process 610. EOS 704 has no direct access to Process Object 901, but instead 
obtains the information it needs by means of functions provided to it l>y KOS 706« 710. Included in the 
information are the UiOs of Stack Ot)jects 902 through 906. Stack Objects 902 to 906 contain the Process 
610's state. 

Stack Objects 902 through 906, are requinsd by CS Id's domain protection metiiod and comprise 
Process 610's MAS 502. Briefly, a domain is determined in part by operations performed when a system is 
operating In that domain. For example, the system Is in EOS 704 domain when executing EOS 704 
operations and in KOS 706, 710 domain when executing KOS 706, 710 operations. A Process 610 must have 
one stack for each domain it enters. In the present embodiment, the number of domains is fixed at four, but 
alternate embodiments may allow any number of domains, and correspondingly, any number of Stack 
Objects. Stack Object ^ comprises Process 610's Secure Stack 504 and is required to store state which 
may be manipulated only by KOS 706, 710< 

Each invocation made by a Process 610 results in the addition of frames to Secure Stack 504 and to 
Macro-Stadc 502. The state stored in the Secure Stack 504 frame includes the macrostate for the invocation, 
the state required to bind Process 610 to a Virtual Processor 612. The frame added to Macro-Stack 502 is 
placed cn one of Stack Objects 902 through 905. Which Stack Objects 902 to 905 gets the frame is 
determir^ by the invoked procedure's domain of execution. 

Rg. 9 shows the condition of a Process 610's MAS 502 and Secure Stack 504 after the Process 610 has 
executed four invocations. Secure Stack 504 has one frame for each invocation; the frames of Process 610's 
MAS 502 are found in Stack Objects 902, 904, and 905. As revealed by their locations. Frame 1 is for an 
Invocation of a routine with KOS 706, 710 domain of execution. Frame 2 for an invocation of a routine with 
the EOS 704 domain of execution, and Frames 3 and 4 for invocations of routines with the User domain of 
execution. Process 610 has not yet invoked a routine with the Data Base Management System (DBMS) 
domain of execution. The frames in Stack Objects 902 through 905 are linked together, and a frame is 
added to or removed from Secure Stack 504 every time a frame is added to Stack Objects 902 through 905. 
MAS 502 and Secure Stack 504 thereby function as a single logical stack even though logically contained in 
five separate Objects. 

8. Processes 610 and Calls (Rgs, 10, 11) 

In the CS 101, calls and returns are executed by KOS 706, 710. When KOS 706, 710 performs a call for a 
process, it does the following: 

It saves the calling invocation's macrostate in the top frame of Secure Stack 504 (Rg. 9). 
It locates the procedure whose Name is contained in the call. The location of the first SIN in the 
procedure becomes the new PBP. 

Using Information contained in the called procedure, KOS 706, 710 creates a new MAS 502 frame in 
the proper Stack Object 902 through 905 and a new Secure Stack 604 frame in Secure Stack 504. FP is 
updated to point to the new MAS 502. If necessary, SDP is also updated. 

Once the values of the ABPs have been updated, the PC is defined. Names can be resolved, and 
execution of the invoked routine can commence. On a return from the invocation to the invoking routine, 
the stack frames are deleted and the ABPs are set to the values saved in the invoking routine's macrostate. 
The invoking routine tiien continues execution at the point following the Invocation. 

A Process 610 may be illustrated in detail by putting the FORTRAN statement A + B Into a FORTRAN 
routirte called EXAMPLE and invoking it from another FORTRAN routine named CALLER. To simplify the 
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example, it is assumed that CALLER and EXAMPLE both have the same domain of execution. The parts of 
EXAMPLE which are of interest look like this: 

^ SUBROUTINE EXAMPLE (C) 

INTEGER X,C 

INTEGER A3 

A = B 

RETURN 
END 

The new eJements are a fomfial argument C, and a new local variable, X. A formal argument is a data 
^ item which receives its value from adata item used in the invoking routine. The format argument's value 
thus varies from invocation to invocation. The portions of INVOKER which are of interest look like this: 

SUBROUTINE INVOKER 

^ IMTIEGERZ 



CALL EXAMPLE (Z) 

30 



END 

^ The CMJ. statement in INVOKER specifies the Name of the subroutine being invoked and the actual 

arguments for the subroutine's fomial arguments. During the invocation, the subroutine's formal 
arguments take on the valu^ of the actual arguments. Thus, during the Invocation specified by this CALL 
statement the formal argument C will have the value represented by the variable Z In INVOKER. 

When INVOKER is compiled, the compiler produces a CALL SIN corresponding to the CALL statement 
^ The CALL SIN contains a Name representing a pointer to the beginning of the called routine's location In a 
procedure object and a list of Names representing the call's actual arguments. When CALL is executed, the 
Names are interpreted to resolve the SIN's Names as previously described, and KOS 710 microcode to 
perform MAS 502 and Secure Stack 504 operations. 

Rg. 10 illustrates the manner in which the KOS 710 call microcode manipulates MAS 502 and Secure 
^ Stadc 504. 

Bg. 10 includes the following elements: 
Call Microcode 1001, contained in FU 120 Writable Control Store 1014. 

PC Device 1002, which contains part of macrostate belonging to the Invocation of INVOKER which is 
executing the CALL statement 
so Registers in FU Registers 1014. Registers 1004 contents include the remainder of macrostate and the 

descriptors corresponding to Names for EXAMPLE'S location and the actual argument Z. 

Procedure Object 1006 contains the entries for INVOKER and EXAMPLE, their Name Tables, and their 

code. 

Macro-Stack Object 1008 (MAS 502) and Secure Stack Object 1010 (Secure Stack 504) contain the 
ss stack frames for the invocations of INVOKER and EXAMPLE being discussed here. EXAMPLE'S frame Is In 
the same Macro-Stack object as INVOKER's frame because both routines are contained in the same 
Procedure Object 1(M36, and therefore have the same domain of execution. 

KOS Call Microcode 1001 first saves the macrostate of INVOKER's invocation on Secure Stack 504, As 
will be discussed later, when the state is saved. KOS 706 Call Microcode 1001 uses other KOS 706 
60 microcode to translate the location information contained in the macrostate into the kind of pointers used 
In MEM 112. Then Microcode 1001 uses the descriptor for the routine Name to locate the pointer to 
EXAMPLE'S entry in Procedure Object 1 006. From the entry, it locates pointers to EXAMPLE'S Name Table 
and the beginning of EXAMPLE'S code- Microcode 1001 takes these pointers, uses other KOS 706 
microcode to translate them into descriptors, and places the descriptors in the locations in Registers 1(XM 
es resevjed for the values of the PBP and NTP. It then updates the values contained in PC Device 1 002 so that 
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when the call is finished, the next SIN to be executed will be the first SIN in EXAMPLE, 

CALL Microcode 1001 next constructs the frames for EXAMPLE on Secure Stack 504 and Macro-Stack 
502. This discussion concerns itself only with Frame 1102 on Macro-Stack 502. Fig. 11 illustrates 
EXAMPLE'S Frame 1102. The size of Frame 1102 is determined by EXAMPLE'S local variables (X, A, and B) 

5 and formal arguments (C). At the bottom of Frame 1102 is Header 1104. Header 1104 contains Information 
used by KOS 706, 710 to manage the stack. Next comes Pointer 1106 to the location which contains the 
value represented by the argument C. In the Invocation, the actual for C is the local variable Z in INVOKER. 
As is the case with all local variables, the storage represented by Z is contained in the stack frame 
belonging to INVOKER's Invocation. When a name interpreter resolved Cs name, it placed the descriptor in 

10 a register. Call Microcode 1001 takes this descriptor, converts it to a pointer, and stores the pointer above 
Header 1104. 

Since the FP ABP points to the location following the last pointer to an actual argument. Call Microcode 
1001 can now calculate that location, convert it into a descriptor, and place it in a FU Register 1004 reserved 
for FP. The next step is providing storage for EXAMPLE'S local variables. EXAMPLE'S procedure Object 

75 1006 contains the size of the storage required for the local variables, so Call Microcode 1001 obtains this 
information from procedure Obfect 1006 and adds that much storage to Frame 1102» Using the new value 
of FP and the Information contained in tfte Name Table Entries for the local data. Name Interpreter 715 can 
now construct descriptors for the local data. For example, A's entry in Name Table specified that It was 
offiset 32 bits from FP, and was 32 bHs long. Thus, Its storage falls between the storage for X and B In Rgure 

20 tL 

9. Memory References and the Virtual Memory Managment System (Rg. 12, 13) 

As already explained, a logical descriptor contains an AON field, an offset field, and a length field. Fig. 
12 illustrates a Physical Descriptor. Physical Descriptor 1202 contains a Frame Number (FN) field, a 

25 Displacement (D) field, and a Length (L) field. Together, the Frame Number field and the Displacement field 
specify the location in MEM 112 comaining the data, and the Length field specifies the length of the data. 

As is dear from the above, the virtual memory management system must translate the AON-offset 
location contained in a logical descriptor 1204 into a Frame Number-Displacement location. It does so by 
associating logical pages with MEM 112 frames. (N.B: MEM 112 frames are not to be confused with stack 

30 frames), fig. 13, illustrates how Macrostack 502 Object 1302 is divided into Logical Pages 1304 In ^ondary 
memory and how Logical Pages 1304 are moved onto Frames 1306 in MEM 112. A Frame 1306 is a fixed- 
size, contiguous area of MEM 112. When the virtual memory management system brings data Into MEM 
112, it does so in frame-sized chunks called Logical Pages 1308. Thus, from the virtual noemory ^stem's 
point of view, each object is divided into Logical Pages 1308 and the address of data on a page consists of 

35 the AON of the data's Object, the number of pages in the object, and Its displacement on the page. In Fig. 
13, the location of the local variable B of EXAMPLE Is shown as it is defined by the virtual memory system, 
a's location is a UID and an offset, or. Inside JP 114, an AON and an offset As defined by the virtual 
memory system, B's location is the AON, the page number 1308, and a displacement within the page. 
When a process references the variable B, the virtual memory management system moves all of Logical 

40 Page 1308 into a MEM 112 Frame 130a B's displacement remains the same, and the virtual memory system 
translates its Logical Page Number 1308 into the number of Frame 1306 in MEM 112 which contains the 
page. 

The virtual memory management system must therefore perform two kinds of translations: (1} AON- 
of^et addresses into AON-page number-displacement addresses, and (2) AON*page number Into a frame 
45 number. 

10, Access Control (Rg. 14) 

Each time a reference is made to an Object, KOS 706, 710 checlcs whether the reference is legaL The 
following discusson will first present the logical structure of access control in CS 101 , and then discuss the 
SO microcode and de\^'ce5 which implement it 

CS 1 01 defines access in terms of subjects, modes of access, and Object size. A process may reference 
a data item located In an Object if three conditions hold: 

1) If the process's subject has access to the Object. 

2) If the modes of access specified for the subject include those required to perform the intended 
5S operation. 

3) If the data item is completely contained in the Object, i.e., if the data item's length added to the data 
Item's offset do not exceed the number of bits In the Object 

The subjects which have access to an Object and tiie kinds of access they have to the Object are 
spedfted by a data structure assodated with the Object called the Access Control List (ACL). An Object's 
$0 size is one of its attributes. Neither an Object's size nor its ACL is contained in the Object Both are 
contained in system tables, and are accessible by means of the Object's UfO. 

Rg. 14 shows the logical structure of access control in CS 101. Subject 1408 has four components: 
Prindpal 1404, Process 1405, Domain 1406, and Tag 1407. Tag 1407 is not implemented in a present 
embodiment of CS 101, so the following description will deal only with principal 1404, Process 1405, and 
65 Domain 1406. 
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Principal 1404 specifies a user for which the process which is making the reference was created; 
Process 1405 specifies the process which Is malcing the reference; and. 

Domain 1406 specifies the domain of execution of the procedure which the process is executing 
when it maices the reference. 

« Ea<* component of the Subject 1408 is represented by a UID. K the UID is a null UID, that component of 
the subject does not affed access checking. Non-null UIDs are the UIDs of Objects that contain information 
about the subject components. Principal Object 1404 contains identification and accounting irtformation 
regarding system users. Process Object 1405 contains process management information, and Domain 
Object 1406 contains information about per-domain error handlers. 

w There may be three modes of acc^ing an Obj^ 1410: read, write, and execute. Read and write are 
self-explanatory; execute is access which allows a subject to execute instructions contained in the Object 
Access Control Usts (ACLs) 1412 are made up of Entries 1414. Each entry two components: Subject 
Template 1416 and Mode Specifier 1418. Subject Template 1416 specifies a group of subjects that may 
reference the Object and Mode Spedfier 1418 specifies the kinds of access these subjects nrwy have to the 

w Object. Logically speaking, ACL 1412 is checked each time a process references an Object 1410. The 
reference may succeed only If the process's current Subject 1408 is one of those on Object 1410*8 ACL 1412 
and If the modes in the ACL Entry 1414 for the Subject 1408 allow the kind of access the process wnshes to 
make. 

20 11, Virtual Processors and Virtual Processor Swapping {Rg. 15) 

As previously mentioned, the execution of a program by a Process 610 cannot take place unl^s EOS 
704 has bound the Process 61 0 to a Virtual Processor 612- Physical execution of the Process 610 takes place 
only while the process's Virtual Processor 612 is bound to JP 114. The following discussion deals with the 
data bases belonging to a Virtual Processor 61 2 and the means by which a Virtual Processor 61 2 is bound to 

25 and removed from JP 1 14. 

Fig- 15 Illustrates the devices and tables which KOS 706, 710 uses to implement Virtual Processors 61 2. 
FU 1 20 WCS contains KOS Microcode 706 for binding Virtual Processors 61 2 to JP 1 14 and removing them 
from JP 114, Timers 1502 and Intemipt Line 1504 are hardy^re devices which produce signals that cause 
the invocation of KOS Microcode 706. Timers 1502 contains two timing devices: Interval Timer 1 506, which 

30 may be set by KOS 706, 710 to signal when a certain time is reached, and Egg Timer 1508, which 
guarantees that there is a maximum time interval for vi/hich a Virtual processor 612 can be bound to JP 1 14 
before it invokes KOS Microcode 706. Interrupt Une 1504 becomes acth« when JP 1 14 receives a message 
from lOS 116« for sample when lOS 116 has finished loading a logical page into MEM 112. 

RJ 120 Registers 508 contain state belonging to the Virtual f^ocessor 612 currently bound to JP 1 14, 

^ Here, this Virtual Processor 612 Is called Virtual Processor A. In addition, Registers 508 contain registers 
reserved for the execution of VP Swapping Microcode 15ia ALU 1942 (part of FU 120} is used for the 
descriptor-to-pointer and pointer-to-descriptor transformations required when one Virtual Processor 61 2 is 
unbound from JP 114 and another bound to JP 1 14. MEM 112 contains data bases for Virtual Processors 
612 and data bases used by KOS 706, 710 to manage Virtual Processors 612. KOS 706, 710 provides a fixed 

40 number of Virtual Processors 612 for CS 101. Each Virtual Processor 612 is represented by a Virtual 
Processor State Block (VPSB) 614. Each VPSB 614 contains infomiation used by KOS 706« 710 to manage 
the Virtual Processor 61 2, and in addition contains information associating the Virtual Processor 61 2 with a 
process. Rg* 15 shows two VPSBs 614, one belonging to Virtual Processor 612At and another belonging to 
Virtual Processor 612B, which vwll replace Virtual Processor 612A on JP 1 14. The VPSBs 614 are contained 

4ff in VPSB Array 151i The index of a VPSB 614 in VPSB Array 1512 is Virtual Processor Number 1514 
belonging to the Virtual Processor 612 represented by a VPSB 614. Virtual Processor Lists 1516 are lists 
which KOS 706, 710 uses to manage Virtual Processors 612. If a Virtual Processor 612 Is able to execute, its 
Virtual Processor Number 1514 is on a list called the Runnable Ust; Virtual Processors 612 which cannot 
run are on other lists, depending on the reason why they cannot run. h is assumed that Virtual Processor 

so 6t2B's Virtual Processor Number 1514 is the first one on the Runnable List. 

When a process is bound to a Virtual Procesor 612, the Virtual Processor Number 1514 Is copied imo 
the process's Process Object 901 and the AONs of the process's Process Object 901 and stacks are copied 
into the Virtual Processor 612's VPSB 614. (AONs are used because a process's stacks are wired acth^e as 
long as the process is bound to a Virtual Processor 612). Binding is carried out by KOS 706, 710 at the 
55 request of EOS 704. In Fig. 15, two Secure Stack Objects 906 are shown, one belonging to the process to 
which Virtual Processor 61 2A is bound, and one belonging to that to which Virtual Processor 61 28 is bound. 

Having described certain overall operating features of CS 101, a present implementation of CS 101's 
structure will be described further next below. 

fit} CS 101 Structural Implementation (Figs. 16, 17. 18, 19, 20) 
1.(IOS1116(Rgs. 16,17) 

Referring to Fig. 16, a partial block diagram of lOS 1 16 is shown. Major elements of lOS 1 16 include an 
ECUPSE® Burst Multiplexer Channel (BMC) 1614 and a NOVA® Data Channel (NDC) 1616, an 10 Controller 
(IOC) 1618 and a Data Mover (DM) 1610. lOS 1 16's data channel devices, for examine BMC 1614 and NDC 
6S 1616, comprise lOS lie's interface to the outside worid. infomiation and addresses are received from 
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external devi«»s. such as disk drives, communications modes, or other computer sv^^"^?' ^ '°f."f/ 
data channel devices and are transferred to DM 1610 (described b^'ow' ^ J^""®" JT^" , wi.v« 
Similarly, information read from MEM 112 is provided through DM 1610to lOS llffsdata diannei devicw 
and thus to the above described external devices. These external devices are a part of CS 101 s addressawe 
* memory space and may be addressed through UID addresses. ., ^, t „»,„i 

IOC 1618 is a general purpose CPU, for example an ECLIPSE® computer available from Data General 
Corporation. A primaiy function of IOC 1618 is control of data transfer through I0S116. In addition, IOC 
leiBoenerates indhridual Mapsfbr each data channel device for translating external device addresses into 
physkal addresses within MEM 112. As indicated in Rg. 16, each data channel device contains an 
individual Address Translation Map (MAP) 1632 and 1636. This allovre lOS 116 to assign individual areas of 
MEM nrs physical address space to each data channel device. This feature provides protection gainst 
one data <4wnnel device writing into or reading from information belonging to another data channel 
device. In addition, IOC 1618 may gwierate overiaptMng address translation Ma^ for two or more^ 
channel devices to allow these date channel devices to share a common area of MEM 1 12 physical address 

80BC8. 

Data transfer between !0S IICs data channel devices and MEM 112 Is through DM 1610, which 
Includes a Buffer memory (BUR 1641. BUF 1641 allows MEM 112 and lOS 116 to operate asychronouslv. 
DM 1610 aiso includes a Ring Grant Generator (RGG) 1644 vi^ich controls access of various data channel 
devices to MEM 112. RGG 1644 is designed to be flexible in apportioning access to MEM 112 among lOS 

20 1 la's data channel devices as loads carried by various data channel devices varies. In addition, RGG 1644 
insures that no one, or group, of data channel devices may monopolize access to MEM 112. 

Referring to Rg. 17, a diagramic representation of RGG 1644's operation is shown. As described further 
in a following description, RGG 1644 may be regarded as a commutator scanning a number of ports which 
are assigned to various channel devices. For example, ports A, C, E, and G may be assigned to a BMC 1614, 

25 ports B and F to a HOC 1616, and ports D and H to anotf^er data channel device. RGG 1644 will scan each of 
these ports in turn and. If the data channel device associated with a particular port is requesting access to 
MEM 1 12, will grant access to MEM 1 12 to that data channel device. If no request Is present at a given port, 
RGG 1644 will continue immediately to the next port Each data channel device assigned one or more ports 
is thereby insured opportunity of access to MEM 112. Unused ports, for example indicating data channel 

so devices which are not presently engaged i n information transfer, are effectively skipped over so that access 
to MEM 1 12 is dynamically modi^ed according to the information transfer loads of the various data channel 
devices. RGG 1644*s ports may be reassigned among lOS 1 16's various data diannel devices as required to 
suit the needs of a particular CS 101 system. If, for example, a particular CS 101 utilizes NDC 1616 more 
than a BMC 1614, that CS 101's NDC 1616 may be assigned more ports while that CS lOI's BMC 1614 Is 

3S assigned fewer ports. 

2. Memory (MEM) 112 (Rg. 18} 

Referring to Rg. 18, a partial block diagram of MEM 112 is shown. Major elements of MEM 112 are 
Main Store Bank (MSB) 1810, a Bank Controller (BC) 1814, a Memory Cache (MC) 1816, a Reld Interface Unit 

-W (RU) 1 820, and Memory Interface Controller (MIC) 1822, Interconnections of these elements with Input and 
output buses of MEM 112 to lOS 116 and JP 114 are indicated. 

MEM 112 is an intelligent, prioritizing memory having a single port to lOS 116, comprised of lOM Bus 
130, MID Bus 129, and lOMC Bus 131, and dual ports to JP 1 14. A first JP 114 port is comprised of MOD Bus 
140 and PD Bus 146, and a second port is comprised of JPD Bus 142 and PD Bus 146. In general, all data 

45 transfers from and to MEM 1 12 by lOS 1 16 and JP 1 14 are of single, 32 bit words; lOM Bus 130, MIO Bus 
129, MOD Bus 140, and JPD Bus 142 are each 32 bits wide. CS 101, however, is a variable word length 
machine wherein the actual physical width of data buses are not apparent to a user. For example, a Narne 
in a user's program may refer to an operand containing 97 bits of data. To the user, that 97 bK data item will 
appear to be read from MEM 1 12 to JP 1 1 4 in a single operation. In actuality, JP 1 14 will read that operand 

so from MEM 112 in a series of read operations referred to as a string transfer. In this example, the string 
transfer will comprise three 32 bit read transfers and one single bit read transfer. The final single bit 
transfer, containing a single data fait, will be of a 32 bit word wherein one bit is data and 31 bits are fill. Write 
operations to MEM 1 1 2 may be performed in the same manner. If a single read or write request to MEM 1 12 
specifies a data item of less than 32 bits of data, that transfer will be accomplished in the same manner as 

55 the final transfer described above. That is, a single 32 bit word will be transferred wherein non-data bits are 
fill bits. 

Bulk data storage In MEM 112 is provided in MSB 1810, which is comprised of one or more Memory 
Array cards (MAsJ 1812. The data path Into and out of MA 1812 is through BC 1814, whidi performs all 
control and timing functions for MAs 1812. BC 18l4's functions include addressing, transfer of data, 
eo controlling vt/hether a read or vwite operation is performed, refresh, sniffing, and error correction code 
operations. All read and write operations from and to MAs 1812 through BC 1814 are in blocks of four 32 bit 
vM>rd8. 

The various MAs 1812 comprising MSB 1810 need not be of the same data storage capacity. For 
example, certain MAs 181 2 may have a capacity of 256 kilobytes while other MAs 1812 may have a capacity 
65 Of 512 kilobytes. Addressing of the MAs 1812 in MSB 1810 is automatically adapted to various MA 1812 
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configurBtions, As indicated in Rg. 18, each MA 1812 contains an address drcuit (A) which receives an 
Input from the next lower MA 1812 indicating the highest address in that next lower MA 181 2. The A circuit 
on an MA 1812 also receives an Input fronn that MA 1812 Indicating the total address space of that MA 1812. 
The A circuit of that MA 1812 adds the highest address input from next lower MA 1812 to its own input 

* representing its own capacity and generates an output to the next MA 1812 indicating its own highest 
addr^. Ail MAs 1812 of MSB 1810 are addressed in parallel by BC 1814. Each MA 1812 compares such 
addresses to its Input from the next lower MA 1812, representing highest address of that next lower MA 
1812, and its own output representing its own highest address, to determine whetfier a particular address 
provided by BC 1814 lies within the range of addresses contained within that particular MA 1812, The 
particular MA 1812 whose address space Includes that address will then respond by accepting the read or 
wrtte request from BC 1814. 

MC 1816 Is the data path for transfer of data between BC 1814 and ICS 116 and JP 114. MC 1816 
contains a high ^ed cache storing data from MSB 1810 which is currently being utilized by eitfier IDS 116 
or JP 114. MSB 1810 thereby provides MEM 112 with a large storage capacity while MC 1816 provides the 
appearance of a high speed memory. In addition to operating as a cache, MC 1 816 includes a bypass write 
path which allows IDS 116 to write blocks of four 32 bit words directly Into MSB 1810 through BC 1814, In 
addition^ MC 1816 Includes a cache write-back path which allows data to be transferred out of MC 181 6's 
cache and stored while further data is transferred into MC isle's cache. Displaced data from MC 1816's 
cache may then be written back into MSB 1810 at a later, more convenient time. This write-back path 

^ enhances speed of operation of MC 1816 by avoiding delays incurred by transfixing data from MC 1816 to 
MSB 1810 before new data may be written into MC 1816. 

MEM 112's FlU 1820 allows manipulation of data formats in writes to and reads from MEM 1 1 2 by both 
JP 114 aid lOS 116. For example, RU 1820 may convert unpacked dedmsl data to packed decimal data, 
and vice versa. In addition, RU 1820 allows MEM 1 12 to operate as a bit addressable memory. For example, 
as described all data transfers to and from MEM 1 12 are of 32 bit words. If a data transfer of less than 32 bits 
Is required, the 32 bit word containing those data bits may be read from MC 1816 to RU 1820 and therein 
manipulated to extract the required data bits. RU 1820 then generates a 32 bit word containing those 
required data bits, plus fill bits, and provides that new 32 bit word to JP 1 14 or lOS 1 16. VWien writing Into 
MEM 112 from lOS 116 through RU 1820, data ts transferred onto lOM Bus 130, read Into RU 1820, 

30 operated upon, transferred onto MOD Bus 140, and transferred from MOD Bus 140 to MC 1816. In read 
operations from MEM 112 to lOS 116, data is transfenred from MC 1816to MOD Bus 140, written into RU 
1820 and operated upon, and transferred onto MK) Bus 129 to ICS 1ia In a data read from MEM 112to JP 
114, data is transferred from MC 1816onto MOD Bus 140, transferred Imo RU 1820 and operated upon, and 
transferred again onto MOD Bus 140 to JP 114. In write operations from JP 114 to MEM 1 12, data on JPO 

35 Bus 142 is transferred into RU 1820 and operated upon, and is then transferred onto MOD Bus 140 to MC 
1816. MOD Bus 140 is thereby utilized as an MEM 112 intemal bus for RU 1820 operations. 

Rnally, MIC 1822 provides primary control of BC 1814, MC 1816, and RU 1820. MIC 1822 lecehres 
control Inputs from and provides control outputs to PD Bus 146 and lOMC Bus 131. MIC 1822 contains 
primary microcode control for MEM 112, but BC 1814, MC 1816, and RU 1820 each include internal 

40 micmcode control, independent, intemal nrwcrocode controls allow BC 1814, MC 1B16, and RU 1820 to 
operate independently of MIC 1822 after their operations have been initiated by MIC 1822. This allows BC 
1814 and MSB 1810, MC 1816, and RU 1820 to operate independently and asynchronously. Efficiency and 
speed of operation of MEM 112 are thereby enhanced by allowing pipelining of MEM 112 operations. 

45 3. Fetch Unit (FU) 120 (Rg. 19) 

A primary function of FU 120 is to execute SINs. In doing so, FU 120 fetehes instructions and data 
(SOPs and Names) from MEM 112, returns results of operations to MEM 112, directs operation of EU 122, 
executes instructions of user's programs, and performs the various functions of CS 101's operating 
systems. As part of these functions, FU 120 generates end manipulates logical addresses and descriptors 

so and Is capable of operating as a general purpose CPU. 

Referring to Rg. 19, a major element of FU 120 is the Descriptor Processor (DESP) 1910. DESP 1910 
Includes General Register RIe (GRF) 506. GRF 506 is a large register array dVlded vertically Into tiriree parts 
which are addressed In parallel. A first part. AONGRF 1932, stores AON fields of logical widresses and 
descriptors. A second part, OFFGRF 1934, stores offs« fields of logical addresses and descriptors and Is 

5$ Utilized as a 32 bit wide general register array. A third portion GRF 506, UENGRF 1936, is a 32 bit wide 
register array for storing length fields of logical descriptors and as a general register for storing data. 
Primary data path from MEM 112 to FU 120 is through MOD Bus 140, which provides Inputs to OFFGRF 
1934. As incficated In Rg. 19, data may be transferred from OFFGRF 1934 to inputs of AONGRF 1932 and 
LENGRF 1936 through various interconnections. SImilarty, outputs from UENGRF 1936 and AONGRF 1932 

60 may be transferred to inputs of AONGRF 1932, OFFGRF 1934, and LENGRF 1936. 

Output of OFFGRF 1934 Is connected to inputs of DESP igWs Arithmetic and Logic Unit lALU) 1942. 
ALU 1942 is a general purpose 32 bit ALU which may be used in generating and manipulating logical 
addresses and descriptors, as distinct from general purpose arithmetic and logic operands performed by 
MUX 1940. Output of ALU 1942 Is connected to JPD Bus 142 to allow results of arithmetic and logic 

€5 operations to be transferred to MEM 1 12 or EU 122. 
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Also connected from output of OFFQRF 1934 is Descriptor Multiplexer (MUX) 1940. An 
1940 is provided to an input of ALU 1942. MUX 1940 is a 32 bit ALU, includmg ^Jlf^'^^'^^Z-yj^t 
maniiuK operations MUX 1940, together with ALU 1942. allows DESP 19 0 o P^J^^J^J^^ 
arithLtic and ligic operations. MUX 1940 and ALU 1942 may allow ar.thmetic I09.C operajons^^^^ 
s operands of greater than 32 bits by performing successive operations upon successive 32 bit words ot 

"""lIoSi^TSiriptors or addresses generated or provided by DESP 1910. are provided to 
Descri^or (LD) Bus 1902. LO Bus 1902 In turn is «>nnected to an input of '^^^jlf 5 ^""J^ton Un^^ 
1928. ATU 1928 Is 8 cache mechanism for converting logical descriptors to MEM 112 physical aescnptors. 

w LD Bus 1902 Is also connected to write Input of Name Cache (NC) 1926. NC 1926 is a cache mechanism 
for storing togical descriptors corresponding to operand Names currently being "^^^h K^Ks 

As previous^ described. Name Table Entries conresponding to operands ^^^J'f^ "^^[^ 

programs are stored in MEM 112. Certain NamaTableEittriesforoperandsof a user's program currently 
Sexecutedare transferred from those NameTabies in MEM 112toFU120andare^^^^ 

IS generate corresponding logical descriptors. These logical descriptors a[ethen stored in NC 19^^ 

described further below, the Instniction stream of a user's program is provided to FU 120 s Instructton 
Buffer (IB) 1962 through MOD Bus 140. FU 120's Parser (P) 1964 separates out. or parses. Names from IB 
1962 and provides those Names as address Inputs to NC 1924. NC ISM'*"^'" Pi^^^'^^'^fff'^J^^P"^^^^ 
outputs to LD Bus 1902, and thus to input of ATU 1928. NC 1926 input from LD "02 allov^ logical 

20 descriptors resulting from evaluation of Name Table Entries to written into NC 1M6. Ws 
Protections Cache (PC) 1934 is a cache mechanism having an input connected ftt>m LD Bus 1802 ar^o 
providing information, as described further below, regarding protection «P«!«8,<»* referents to d^^ 
MEM 112 by user's programs. NC 1926, ATU 1928, and PC 1934 are thereby acceleration mechanwms of, 
respectively, CS 101's Namespace addressing, logical to physical address structure, and protection 

* ""^efe'^g again to DESP 1910, DESP 1910 includes BIAS 1982. connected from 

As previously described, operands containing more than 32 data bits are transferred beteen MEM 1 12 arid 
JP 114 by means of string transfers. In order to perform sting transfers, » ^ rwcassary for PU 120 to 
generate a corresponding succession of logical descriptors wherein 'jW'fl* ^e"* °* ""^ 

30 descriptors is no greater than 5 bits, that is, specify lengths of no greater «>an^ date 0^ 

A logical descriptor describing a data item to be transferred by meare of a rtnng ^'^^'f? 
in GRF M6. AON field of the logical descriptor will reside in AONGRF 1932. 0 field m 0RF6RF and L 
field in LENGRF 193a At each successwe transfer of a 32 bit word in the strii^ transfw. O fle d oT mat 
original logical descriptor will be incremented by the number of data bits transferred while L field will be 

35 8c«.rdingly decremented. The logical descriptor residing in QRF 506 will *"?^,<'eaOTto, upon each 
successsive transfer of the string transfer, that portion of the data item yet to be tran^rred. O fl«d m 
OFFGRF 1934 will indicate increasinglY larger offsets into that data *^'^^^^lff..^l."^^ 
successively shorter lengths. AON and O fields of the logical descnptor In GRF "fV^e utilized cfiredrt^ 
as AON and O fields of the successive logical descriptors of the string transfer. L field of '^Cf' 

40 descriptor residing in LENGRF 1936. however, may not be so used as L fields of the suarMSive strmg 
trensf^r logical descriptors as this L field indicates remaining length of data item ye^ » be Weir^^ 
instead. BIAS 1952 generates the 5 bit L fields of successive stnng transfer logical descriptors while 
correspondingly decrementing L field of the logical descriptor in LENGRF 1936. Duniig each transfer, BIAS 
1952 generates L field of the next string transfer logical descriptor while concurrently providing "-field of 

4S the cJrrBnt string transfer logical descriptor. By doing so. BIAS 19K tiiereby incr*«s«^^^^^ 

of string transfe^ by performing pipelined Lfield operations. BIAS 1952 thereby allows CS 101 to appaarto 
the user to be a variable word length machine by automatically performing stnng transfere. "Riis 
mechanism is used for transfer of any data Item greater than 32 bits, for example double precision floating 

50 ""'"FinaE^Fu'lZO includes microcode circuitry for controlling all FU 120 operations described above. In 
particular, FU 120 includes a microinstruction sequence control store (mC) 1920 stonng sequences of 
microinstructions for controlling step by step execution of all FU 120 operations. In S«"e"'' *«^A,^^^^20 
operations «in into two classes. A first class includes those microinstruction sequences dir^rtly concerned 
^ executing tiie SOPs of user's programs. The second clai» *!,?"^^^ 

ss concerned wfth CS lOI's operating systems, including and certain automatic mtemal FU 120 functions 
su^ as evaluation of Name Table Entries. . 

As previously described. CS 101 is a multiple S-Language machine. For example. mC 1SC0 may conta n 
m-|croir»tnietion sequences for executing user's SOPs In at least four d'ffe/ent D.ale<^. mC 
comprised of a writeable control store and sets of microinstrurtion sequences for ^^rious Dialecte rnay be 

„ transferred into and out of mC 1920 as required for execution of various user's programs. By stonng sete of 
microinstruction sequences for more than one Dialect in mC 1920, tt is possible for ^^^'^^^"^'^J^^ 
written in a mixture of user languages. R»r example, a particular user's program may be w"«en primaril^^ 
FORTRAN but may call certain COBOL routines. These COBOL routines will be correspondingly translated 
into COBOL dialect SOPs and executed by COBOL microinstruction sequences stored in mC 1820. 

es -nie instruction stream provided to FU 120 from MEM 112 has been previously described with 
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reference to Fig. 3. SOPs and Names of this instruction stream are transferred from MOD Bus 140 into IBi 
1962 as they are provided from MEM 112. IB 1962 includes two 32 bit (one word) registers. IB 1962 also 
includes prefetch circuitry for reading for SOPs and Names of the Instruction stream from MEM 1 12 in such 
8 manner that IB 1962 shall always contain at least one SOPs or Name, FU 120 includes (P) 1964 which 

5 reads and separates, or parses, SOPs and Names from IB 1962. As previously described. P 1964 provides 
those Names to NC 1926, which accordingty provides logical descriptors to ATU 1928 so as to read the 
corresponding operands from MEM 112. 

SOPs parsed by P 1964 are provided as inputs to Fetch Unit Dispatch Table (FUDT) 1904 and Execute 

Unit Dispatch Table (EUDT) 1966. Referring first to FUDT 1904, FUDT 1904 Is effectively a table for 
w translating SOPs to starting addresses in mC 1912 of corresponding microinstruction sequences. This 
Intermediate translation of SOPs to mC 1912 addresses allows efficient paddng of microinstruction 
sequences within mC 1912. That is, certain microinstruction sequences may be common to two or more»- 
S-I^nguage Dialects. Such microinstruction sequences may therefore be written into mC 1912 once andy 
may be referred to by different SOPs of different S-Language Dialects. 
IS EUDT 1966 performs a similar function with r^pect to EU 122. As will be described below, EU 122 
contains a mC, similar to mC 1912, which is addressed through EUDT 1966 by SOPs specifying EU 122 
operations. In addition, FU 120 may provide such addresses mC 1912 to initiate EU 122 operations as 
required to assist certain FU 120 operations. Examples of such operations which may l>e requested by FU 
120 include calculations required in evaluating Name Table Entries to provide logical descriptors to be 
20 loaded into NC 1926. 

Assodated with both FUDT 1S04 and EUDT 1966 are Dialect (D) registers 1905 and 1967. D registers 
1905 and 1967 store information indicating the particular S-Language Dialect currently being utilized in 
execution of a user's program. Outputs of D registers 1905 and 1967 are utilized as part of the address 
inputs to mC 1912 and EU 122's mC. 

25 

4. Execute Unit (EU) 122 (Rg. 20) 

. As previously described, EU 122 is an arithmetic and logic unit provided to relieve FU 120 of certain 
arithmetic operations. EU 122 is capable of performing addition, subtraction, muHipfication, and dh^ision 
operations on integer, packed and unpacked decimal, and single and double predsion floating operands. 

30 EU 122 is an independently operating microcode controlled machine including Microcode Control (mC) 
2010 which, as described above, is addressed by EUDT 1966 to initiate EU 122 operations. mC 2010 also 
includes logic for handling mutual intermpts between FU 120 and EU 122. That is. FU 120 may Interrupt 
current EU 122 operations to call upon EU 122 to assist an FU 120 operation. For example, FU 120 may 
interrupt an arithmetic operation cun^ently being executed by EU 122 to call upon EU 122 to assist in 

35 generating a logical descriptor from a Name Table Entry. 

Similarly, EU 122 may inte^upt current FU 120 operations when EU 122 requires FU 120 assistance in 
executing a current arithmetic operation. For example, EU 122 may Imerrupt a current FU 120 operation if 
EU 122 receives an instruction and operands requiring EU 122 to perform a drvide by zero. 

Referring to Rg. 20, a partial block diagram of EU 122 is shown. EU 122 includes two arithmetic and 

40 logic units. A first arithmetic and logic unit (MULT) 2014 is utilized to perform addition, subtraction, 
multiplication, and division operations upon Integer and decimal operands, and upon mantissa flelds of 
single and double precision floating point operands. Second ALU (EXP) 2016 is utilized to perform 
operations upon single and double precision floating point operand exponent fields in parallel with 
operations performed upon floating point mantissa fields by MULT 2014. Both MULT 2014 and EXP 2016 

4S include an arithmetic and logic unit, respectively MALU 2074 and EXPALU 2084. MULT 2014 and EXP 2016 
also Indude register flies, respecth^ely MRF 2050 and ERF 2080, which operate and are addressed in parallel 
in a manner similar to AONGRF 1932, OFFGRF 1984 and LENGRF 1936. 

Operands for EU 122 to operate upon are provided from MEM 112 through MOD Bus 140 and are 
transferred Into Operand Buffer (OPB) 2022. In addition to serving as an input buffer, OPB 2022 performs 

so certain data format manipulation operations to transform input operands Into formats most efficiently 
operated whh by EU 122. In particular, EU 122 and MULT 2014 may foe designed to operate efficientiy with 
packed dedmal operands. OPB 2022 may transform unpacked decimal operar^ds into packed decimal 
operands. Unpacked decimal operands are in the form of ASCII characters wherein four bits of each 
characters are binary codes spedfying a decimal value b^een zero and nine. Other bits of each character 

ss are referred to as zone fields and in general contain information identifying particular ASCII characters. For 
example, zone field bits may specify whether a particular ASCII diaracter is a number, a letter, or 
punctuation. Packed dedmal operands are comprised of a series of four bit fields wherein each field 
contains a binary number specifying a decimal value of between zero and nine. OPB 2022 converts 
unpacked decimal to packed dedmal operands by extracting zone field bits and packing the four numeric 

60 value bits of each character Into the four bit fields of a packed decimal number. 

EU 122 IS also capable of transforming the results of arithmetic operands, for example in packed 
dedmal format. Into unpadeed decimal format for transfer back to MEM 112 or FU 120. In this case, a 
packed decimal result appearing at output of MALU 2074 is written into MRF 2050 through a multiplexer, 
not shown in Fig. 20, vy^idi transforms the four bit numeric code fielcfe of the packed dedmal results into 

6 corresponding bits of unpacked dedmal operand characters, and forces blanks into the zone field bits of 
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those unpacked decimal characters. The results of this operation are then read from MRF ' 
2074 and zone field bits for those unpacked decimal characters are read from Constant Store (C^J 2060 to 
MALU 2074. These inputs from MRF 2050 and CST 2060 are added by MALU 2074 to generate final result 
outputs in unpacked dedmal format These final results may then be transferred onto JPD Bus 142 through 

* Output Multiplexer (Oi\fl) 2024. , . 

Considering first floating point operations, in addition or subtraction of floatmg point operands it is 
necessary to equalize the values of the floating point operand exponent fields. This is referred to as 
prealignment in floating point operations, exponent fields of the two operands are transferred into 
EXPALU 2034 and compared to determine the difference between exponent fields. An output representing 

» difference between exponent fields Is provided from EXPALU 2034 to an input of floating point control 
(FPC) 2002 FPC 2002 in turn provides control outputs to MALU 2074, which has received the mantissa fields 
of the two operands. MALU 2074, operating under direction of FPC 2002, accordingly right or left shifts one 
operand's mantissa field to effectively align that operand's exponent field with the other operands 
exponent field. Addition or subtraction of the operand's mantissa fields may then proceed. 
' EXPALU 2034 also peribnms addition or subtraction of floating point operand exponent fields in 
muttiplica^on or cfivislon operations, while MALU 2074 performs multiplication and division of the operand 
mantissa fields. Multiplication and dhrision of floating point operand mantissa fields by MALU 2074 is 
performed by successive shifting of one operand, corresponding generation of partial products of the other 
operand, and successive addition and subtraction of those partial products, 

^ Rnally, EU 122 performs normalization of the results of floating point operand operations by left 
shifting of a final result's mantissa field to eliminate zeros in the most significant chara<^ers of the final 
resuh mantissa field, and corresponding shifting of tiie final result exponent fields. Normalization of 
floating point operation results is controlled by l=PC 2002. FPC 2002 examines an unnormalized floabng 
point resuh: output of MALU 2074 to detect which, rf any, of the most significant characters of that results 

^ contain zeros. FPC 2002 then accordingly provides control outputs to EXPALU 2034 and MALU 2074 to 
correspondingly shift the exponent and mantissa fields of those results so as to eliminate leading character 
zeros from the mantissa field. Nonmalized mantissa and exponent fields of floating point results may then 
be transferred from MALU 2074 and EXPALU 2034 to JPD Bus 142 through OM 2024. ^ ^ , . 

As described above, EU 122 also perfomns addition, subtraction, multiplication, and division 

3tf operations on operands. In this respect, EU 122 uses a leading zero detector in FPC 2002 in efficiently 
performing multiplication and division operations. FPC 2002's leading zero detector examines the 
characters or bhs of two operands to be multiplied or divided, starting from the highest, to determine 
which, if any, contain zeros so as not to require a multiplication or dwision operation. FPC 2002 accordingly 
left shifts the operands to effectively eliminate those characters or bits, thus reducing the number of 

35 operations to multiply or divide the operands and Mcordingly reducing tine time required to operate upon 

the operands. 

Finally, EU 122 utilizes a unique method, with associated hardwanft, for performing arltnmetic 
operations on decimal operands by utilizing circuHry which Is otherwise conventionally used onhr to 
perform operations upon floating point operands. As described above, MULT 2074 is designed to operate 

<o with packed decimal operands, that is operands in tiie fomi of consecutive blocks of four bits wtierein each 
block of four bits contains a binary code representing numeric values of between zero and nine. Roating 
point operands are similarly in the form of consecutive blocks of four bits. Each block of four bits in a 
floating point operand, however, contains a binary number representing a hexadecimal value of between 
zero and fifteen. As an initial step in operating vwtii packed decimal operands, tiiose operands are loaded, 

^ one at a time, into MALU 2074 and, with each such operand, a number comprised of all hexadedmal sixes 
is loaded into MALU 2074 from CST 2060. Tliis CST 2060 number is added to each packed decimal operand 
to effectively convert those packed decimal operands into hexadecimal operands wherein tiie four bit 
blocks contain numeric values in the range of sbc to fifteen, rather than in the original range of zero to nine. 
MULT 2014 then performs arithmetic operation upon those transformed operands, and in doing so detects 

so and saves information regarding which four bit characters of those operands have resulted in generation of 
canies during the arithmetic operations. In a final step, the intermediate result resulting from completion of 
those arithmetic operations upon those transfomied operands are reconverted to packed decimal format 
fay subtraction of hexadecimal sixes from those characters for which carries have been generated. 
Effectively, EU 122 converts packed decimal operands into "Excess Six" operands, performs arithmetic 

ss operations upon tiiose "Excess Six" operands, and reconverts "Excess Six" results of those operations 
back into packed decimal format r-^t^n^. A-r-itii^^o 

Rnally, as previously descibed FU 120 controls transfer of arithmetic results from EU 122 to MEM 1 12. 
In doing so, FU 120 generates a logical descriptor describing the size of MEM 112 address space, or 
"container", that result is to be transferred into. In certain arithmetic operations, for example Integer 

so operations, an arithmetic result may be larger than anticipated and may contain more bits than the MEM 
112 "container". Container Size Check Circuit (CSC) 2052 compares actual size of arithmetic results and L 
fields of MEM 112 "container" logical descriptors. CSC 2052 generates an output indicating whether an 
MEM 112 "container is smaller than an arithmetic result 



these 



Having briefly described certain features of CS 101 structure and operation in the above overview, 
e and other features of CS 101 y^W be described in furtiier detail next below m a more detailed 
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mtroduca'on of CS 101 structure ancl operation. Then, in further descriptions, these and other features of CS 
101 structure and operation will be descnbed in depth. 

1. Introduction (Rgs. 101—110) 

A. General Structure and Operation (Fig 101) 
a. General Structure 

Referring to Rg. 101, a partial block diagram of Computer System (CS) 10110 Is shown. Major elements 
of CS 10110 are Dual Port Memory (MEM) 10112, Job Processor (JP) 10114, Input/Output System (lOS) 
101 16, and Diagnostic Processor (DP) 101 18. JP 101 14 includes Fetch Unit (FU) 10120 and Execute Unit |EU) 
10122. 

Referring first to lOS 10116, lOS 10116 is interconnected with Extemal Devices (ED) 10124 through 
Input/Output (I/O) Bus 10126. ED 10124 may include, for example, other computer systems, keyboard/ 
display units, and disc drive memori^. lOS 10116 is interconnected with Memory Input/Output (MIO) Port 
10128 of MEM 10112 through Input/Output to Memory (tOM) Bus 10130 and Memory to Input/Output (MiO) 
Bu5 10129, and with FU 10120 through I/O Job Processor (lOJP) Bus 10132. 

DP 10118 is interconnected with, for example, extemal keyboard/CRT Display Unit (DU) 10134 through 
Diagnostic Processor Input/Output (DPIO) Bus 10136. DP 10118 is interconnected with lOS 10116, MEM 
10112, FU 10120, and EU 10122 through Diagnostic Processor (DP) Bus 10138. 

Memory to Job Processor (MJP) Port 10140 of Memory 10112 is interconnected with FU 10120 and EU 
10122 through Job Processor Data (JPD) Bus 10142. An output of MJP 10140 Is connected to inputs of FU 
10120 and EU 10122 through Memory Output Data (MOD) Bus 10144. An output of FU 10120 is connected to 
an input of MJP 10140 through Physical Descriptor (PD) Bus 10146. FU 10120 and EU 10122 are 
interconneded through Fetch^ecute (F/E) Bus 1014a 

b. General Operation 

As will be discussed further below, lOS 10116 and MEM 10112 operate independently under general 
control of JP 10114 in executing multiple user's programs. In this regard, MEM 10112 is an intelligent 
prioritizing memory having separate and independent ports MI0 10128 and MJP 101 40 to lOS 101 16and JP 
10114 respectively. MEM 10112 is the primary path for information transfer between Extemal Devices 
10124 (through lOS 10116) and JP 10114. MEM 10112 thus operates both as a buffer for receiving and 
storing various individual user's programs (e.g., data, instructions, and results of program execution) and 
as a main memory for JP 10114. 

A primary function of lOS 101 16 is as an input/output buffer between CS 101 10 and ED 10124. Data and 
Instructions are transferred from ED 10124 to lOS 10116 through I/O Bus 10126 in a manner and format 
compatible with ED 10124. lOS 10116 recent and stores this information, and manipulates the 
information into formats suitable for transfer into MEM 10112. lOS 10116.then indicates to MEM 101 12 that 
new information is available for transfer Imo MEM 10112. Upon acknowledgemerrt by MEM 10112, this 
Information Is transferred into MEM 10112 through lOM Bus 10130 and MIO Port 1012a MEM 10112 stores 
the information in selected portions of MEM 101 12 physical address space. Atthis time, 108 10116 notifies 
JP 10114 that new information is present in MEM 10112 by providing a "semaphore" signal to FU 10120 
through lOJP Bus 10132. As will be described further below, CS 10110 manipulates the data and 
instructions stored in MEM 10112 into certain information structures used In executing user's programs. 
Among these structures are certain structures, discussed further below, whidi are used by CS 10110 In 
organizing and controlling flow and execution of user programs. 

FU 10120 and EU 10122 are independently operating microcode controlled "machines" together 
comprising the CS 10110 micromachlne for executing user's programs stored In MEM 101 12. Among the 
principal functions of FU 10120 are: (1 ) fistching and interpreting Instructions and data from MEM 10112 for 
use by FU 10120 and EU 10122; (2) organizing and controlling flow of user programs; (3) initiating EU 1 01 22 
operations; (4) performing arithmetic and logic operations on data; (5) controlling transfer of data from FU 
10120 and EU 10122 to MEM 10112; and, (6) maintaining certain "stadc" and "register" mechanisms, 
described i>elow. FU 1 0120 "cache" medianlsms, also described below, are provided to enhance the speed 
of operation of JP 10114. These cache mechanisms are acceleration circuitry including, in part, high speed 
memories for storing copies of selected information stored in MEM 10112. The information stored in this 
acceleration circuitry is therefore more rapidly available to JP 10114. EU 10122 is an arithmetic unit capable 
of executing Integer, decimal, or floating point arithmetic operations. The primary function of EU 10122 is 
to relieve FU 10120 from certain extensive arithmetic operations, thus enhancing the efficiency of CS 101 10. 

In general, operations in JP 101 14 are executed on a memory to memory basis; data is read from MEM 
10112, operated upon, and the results returned to MEM 10112. in this regard, certain stack and cache 
mechanisms in JP 10114 (described below) operate as extensions of MEM 10112 address space. 

In operation, FU 10120 reads data and instructions from MEM 10112 by providing physical addresses 
to MEM 101 12 byway of PA Bus 10146 and MJP Port 10140. The instmctions and data are transferred to FU 
10120 and EU 10122 by way of MJP Port 10140 and MOD Bus 10144. Instructions are interpreted by FU 
10120 microdode circuitry, not shown in Rg. 101 but described below, and when necessary, microcode 
instructions are provided to EU 10122 from FU 10120's microcode control by way of F/E Bus 10148, or by 
way of JPD Bus 10142. 
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As stated above, FU 10120 and EU 10122 operate asynchronously with respect to each other's 
functions, A microinstruction from FU 10120 microcode circuitryr to EU 10122 may initiate a selected 
operation of EU 10122. EU 10122 may then proceed to Independently execute the selected operation. FU 
10120 may proceed to concurrently execute other operations while EU 10122 is completing the selected 

^ arithmetic operation. At completion of die selected arithmetic operation, EU 10122 signals FU 10120 that 
the operation results are available by way of a "handshake" signal through F/E Bus 10148. FU 10120 may 
then receive the arithmetic operation results for further processing or, as discussed momentarily, may 
directiy transfer the arithmetic operation results to MEM 101 1 2. As described further below, an instruction 
buffer referred to as a "queue" between FU 10120 and EU 10122 allows FU 10120 to assign a sequence of 

w arithmettc operations to be performed by EU 10122. 

Information, such as results of executing an Instruction, is written into MEM 10112 from FU 10120 or 
EU 10122 by way of JPD Bus 10142. FU 10120 provides a "physical write address" signal to MEM 10112 by 
way of PA Bus 10146 and MJP Port 10140. Concunrentiy, the Information to be written into MEM 10112 is 
placed on JPD Bus 10142 and is subsequently written Into MEM 10112 at the locations selected by the 
physical write address. 

FU 1 0120 places a semaphore signal on lOJP Bus 10132 to signal to lOS 1 01 16 that information, such as 
the results of executing a user's program, is available to be read out of CS 10110. lOS 10116 may then 
transfer the information from MEM 10112 to lOS 10116 by way of MIO Port 10128 and lOM Bus 10130. 
Information stored in iOS 101 16 is then transferred to ED 10124 through i/O Bus 10126. 

20 During execution of a user's progranri, certain information required by JP 101 1 6 may not be available in 
MEM 10112- In such cases as further described in a following discussion, JP 101 14 may write a request for 
information into MEM 10112andnotify IOS 10116, by wayof lOJP Bus 10132, that such a request has been 
made, IOS 101 16 will tiien read the request and transfer the desired information from ED 10124 into MEM 
10112 through IOS 10116 in the manner described above. In such operations, IOS 10116 and JP 10114 

2S operate together as a memory manager wherein the memory space addressable by JP 10114 is termed 
virtual memory space, and includes both MEM 10112 memory space and all external devices to which IOS 
10116 has access. 

As previously described, DP 10118 provides a second interface between Computer System 10110 and 
the external worid byway of DPIO Bus 10136. tiP 10118 allows DU 10134, for example a CRT and keyboard 

30 unit or a teletype, to perform all functions which are conventionally provided by a hard <i.e., switches and 
tights) console. For example, DP 101 18 allows DU 101 34 to exercise control of Computer System 101 10 for 
such purposes as system initialization and start up, execution of diagnostic processes, and fault monitoring 
and Identification. DP 101 1 8 has read and wrhe access to most memory and register portions within each of 
IOS 10116, MEM 10112. FU 10120, and EU 10122 by way of DP Bus 10138. Memories and registers in CS 

3s 10110 can therefore be directiy loaded or initialized during system start up, and can be directly read or 
loaded with test and diagnostic signais for fault monitoring and identification. In addition, as described 
furtiier below, microinstructions may be loaded into JP 101 14's microcode circuitry at system start up or as 
required. 

Having described the general structure and operation of Computer System 10110, certain features of 
Computer System 101 10 will next be briefly described to aid in understanding the following, more detailed 
descriptions of these and other features of Computer System 101 10. 

a Definition of Certain Terms 

Certain terms are used relating to the structure and operation of CS 10110 throughout the following 
^ discussions. Certain of these terms will be discussed and defined first to aid in understanding the following 
descriptions. Other terms will be Introduced In the following descriptions as required. 

A procedure is a sequence of operational steps, or instructions, to be executed to perform some 
operation. A procedure may include data to be operated upon in performing the operation. 

A program \s a static group of one or more procedures. In general, programs may be classified as user 
so programs, utility programs, and operating system programs. A user program is a group of procedures 
generated by and private to one particular user of a group of users interfacing with CS 10110. Utility 
programs are commonly available to all users; for example, a compiler comprises of a set of procedures for 
compiling a user language program into an S-language program. Operating system programs are groups 
of procedures internal to CS 10110 for allocation and control of CS lOllO resources. Operating system 
ss programs also define Interfaces within CS 10110. For example, as will be discussed further below all , 
operands in a program are referred to by "NAME". An operating system program translates operand 
NAME Into tiie physical locations of the operands in MEM 10112. The NAME translation program thus 
defines the Internee between operand NAME (name space addresses) and MEM 101 1 2 physical addresses. 
A process is an independent locus of control passing through physical, logical or virtual address 
GO spaces, or, more particularty, a path of execution through a series of programs (i.e., procedures). A process 
will generally include a user program and data plus one or more utility programs <e.g., a compiler) and 
operating system programs necessary to execute the user program. 

An o6yect is a uniquely iden^afoie portion of "data space" accessible to CS 10110. An object may be 
regarded as a container for Information and may contain data or procedure information or both. An object 
65 may contain for example, an entire program, or set of procedures, or a single bit of data. Objects need not 
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be contiguously located in the data space accessible to CS 10110, and the information contained in an 
object need not be contiguously located in that object. 

A domain is a state of operation of CS 10110 for the purposes of CS 10110's protection mechanisms. 
Each domain is defined by a set of procedures having acc^s to objects within that domain for their 

^ exeojtion. Each object has a single domain of execution in which it is executed if it is a procedure objecc or 
used, if it is a data object CS 10110 is said to be operating In a particular domain If It Is executing a 
procedure having that domain of execution. Each object may belong to one or more domains; an object 
belongs to a domain if a procedure executing in that domain has potential access to the object CS 10110 
may, for example have four domains: User domain, Data Base Management System (DBMS) domain. 
Extended Operating System (EOSI domain, and Kernel Operating System (KOS) domain. User domain is 
the domain of execution of atl user provided procedures, such as user or utility procedures. DBMS domain 
Is the domain of execution for operating system procedures for storing, retrieving, and handling data. EOS 
domain Is tiie domain of execution of operating system procedures defining and forming the user level 
Interface imth CS 10110, such as procedures for controlling an executing files, processes, and 1/0 
operations. KOS domain is the domain of execution of the low level, secure operating system which 
manages and controls CS 10110's physical resources. Other embodiments of CS 101 10 may have fewer or 
more domains than those just described. For example, DBMS procedures may be Incorporated into the 
EOS domain or EOS domain may be divided by incorporating the I/O procedures into an 1/0 domain. There 
is no hardware enforced limitation on the number of, of boundaries between, domains in CS 101 10. Certain 

20 CS 10110 hardware functions and structures are, however, dependent upon domains. 

A subfect Is defined, for purposes of CS 10110's protection mechanisms, as a combination of the 
current principle (user), the current process being executed, and the domain the process is currentiy being 
executed in. In addition to principle, process, and domain, which are identified by UIDs, subject may 
include a Tag, which is a user assigned identification code used where added security is required. For a 

^ given process, principle and proc^ are constant but the domain is determined by the procedure currently 
being executed. A process's associated subject is therefore variable along the path of execution of the 
process. 

Having discussed and defined the above terms, certain features of CS 10110 wilt next be briefly 
described. 

30 

d. Multi-Program Operation 

CS 10110 is capable of concurrently executing two or more programs and selecting the sequence of 
execution of progranrw to make most effective use of CS 10110'b resources. This is referred to as 
multiprogramming. In this regard, CS 10110 may temporarily suspend execution of one pmgram, for 

35 example when a resource or certain information required for tfiat program is not immediately available, 
and proceed to execute another program until the required resource or information becomes available. For 
example, particular information required by a first program may not be available in MEM 10112 when 
called for. JP 10114 may, as discussed further below, suspend execution of the first program, transfer a 
request for that information to lOS 10116, and proceed to call and execute a second program. lOS 10116 

^ would fetch the requested information from ED 10124 and transfer it into MEM 101 12. At some time after 
lOS 10116 notifies JP 10114 that the requested information Is available in MEM 10112, JP 10114 could 
suspend execution of the second program and resume execution of the first program. 

e. Multi-Language Operation 

45 As previously described, CS 10110 is a multiple language machine. Each program written In a high 
level user language, such as COBOL or FORTRAN, is compiled into a corresponding Soft (S> Language 
program. That is. In terms of a conventional computer system, each user level language has a 
corresponding machine language, classically defined as an assembly language. In contrast to classical 
assembly languages, S-Languages are mid-level languages wherein each command in a user's high level 

so language is replaced by, in general, two or three S-Language Instructions, refen^d to as SINs. Certain SlNs 
may be shared by two or more high level user languages. CS 10110, as further described in following 
discussions, provides a set, or dialect, of microcode instructions (S-lnterpreters) for each S-Language. S- 
Interpreters interpret SINs and provide corresponding sequences of microinstructions for detailed control 
of CS 10110. CS 10110's Instrtiction set and operation may therefore be tailored to each user's program, 

ss regardless of the particular user language, so as to most effidentiy execute the user's program. Computer 
System 10110 may, for example, execute programs in both FORTRAN and COBOL with comparable 
effldency. In addition, a user may write a program In more tiian one high level user language without loss 
of efficiency. For example, a user may write a portion of his program in COBOU but may wish to write 
certain portions in FORTRAN, In such cases, the COBOL portions would be compiled into COBOL SINs and 

«> executed with the COBOL dialect S-lnterpreter. The FORTRAN portions would be compiled into FORTRAN 
SINs and executed with a FORTRAN dialect S-lnterpreter. The present embodiment of CS 101 10 utilizes a 
uniform format for all SINs. This feature allows simpler S-lnterpreter structures and increases efficiency of 
SIN interpretation because it is not necessary to provide means for interpreting each dialect individually. 

es 
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f. Addressing Structure 



' Each object created for use in, or by operation of, a CS 10110 is permanently assigned a Unique 
Identifier (UID). An object's UID allows that object to be uniquely identified and located at any ttme, 
reaardless of whici> particular CS 101 10 "it was created by or for or where it is subsequently located. Thus 
s each time a new object is defined, a new and unique UID is allocated, much as social security numbers are 
allocated to Individuals. A particular piece of information contained in an object may be located by a logical 
address comprising the object's UID, an offeet from the start of the object of the first brt of the wgrnent, and 
the length (number of Wts) of the information segment. Data within an object ryay therefore be addressed 
on a Wt granular basis. As will be described further in following discussions, UID s are used widiin a CS 
to 101 10 as logical addressee and, for example, as pointers. Logically, all addresses and pointers in CS 101 10 
are UID addresses and pointBrs. As previously described and as described below however, short, 
temporary unique identlflere. valid only within JP lOIUand referred to as Active Object Numbers are used 
within JP 101 14 to reduce die wid* of address buses and amount of address information hand'ed. 
An object becomes a<*ve in CS 10110 when it is transferred from backing store CED 10124 to MEM 
fS 10112 for use in executing a process. At this time, each such object is assigned an Active Object Number 
(AON). AONs are short unique identifiers and are related to the object's UIDs trough <»?a'n CS I WO 
information structures described below. AONs are used only witWn JP 10114 and are used in JP 10114, in 
place of UIDs. to reduce the required width of JP 101 14's address buses and the aniount of address data 
handled In JP 101 14. As with UID logical addresses, a piece of data In an o«ect may ba addressed through 
20 a bit granular AON logical address comprising the object's AON, an offeet from the start of the object of the 
first bit of the piece, and the length of the piece. ip ini id 

The transfer of logical addresses, for example pointers, between MEM 10112 W'^'H.i -2 2 

(AONs) during execution of a process requires translations between UIDs and AONs. As will be descnbed 
in a later discussion, this translation is accomplished, in part, through the informafion ^otures 
25 mentioned above. Similariy, translation of logical addresses to physical address^ M^Jf"?' *° 
physically access information stored in MEM 10112, is accomplished through CS 10110 information 
structures relating AON logical addresses to MEM 10112 physical addresses. ^ ^ ^ 

Each operand appearing in a program is assigned a Name when the program is compiled. Thereafter, 
all references to the operands are through their assigned Names. As will be d«cnbed in detad m a later 
30 discussion. CS 10110-8 addressing structure includes a mechanism for recognizing Names as they appear 
in an Instruction stream and Name Tables containing directions for resolving Names to AON logical 
addresses. AON logical addresses may then be evaluated, for example translated mto a MEM 10112 
physical address, to provide actual operands. The use of Names to idertify operands In the Insti^iotiorB 
stream (process) (1) allows a complicated address to be replaced by a simple refererM» of uniforiii format; 
35 12) does not require that an operation be directly defined by data type in the instruction stream: (3) allows 
repeated references to an operand to be made in an Instruction stream by merely repeating the operand s 
Name: and, (4) allovw partially complied Name to address translations to be stor^ in a cadie to speed »«i 
operand references. The use of Names thereby substantially reduces the volume of information required m 
the Instruction stream for operand references and increases CS 1 01 10 speed and efficiency by performing 
M operands references through a parallel operating, underlying mechanism. ,.bb-i w ,.,,.1, 

finally CS 10110 address structure incorporates a set of Architectural Base Pointers (ABPs) for each 
process. ABPs provide an addressing framework to locate data and procedure information belonging to a 
process and are used, for example. In resolving Names to AON logical addresses. 

« g. Protection Mechanism „»i„:„„ ♦„ 

CS lOnO's protection mechanism is constructed to prevent a user from (1) gaining access to or 
disrupting another user's process, including data, and (2) interi^ering with or otherwise subverting the 
operation of CS 10110. Access rights to each particular acth^e object are dynamically granted as a function 
of the currently active subject A subject is defined by a combination of the current pnnciple (user), the 
current process being executed, and the domain in which the process is cun-ently being executed. In 
addition to principle, process, and domain, subject may include a Tag, which is a user assigned 
Identification code used where added security is required. For a given process, the pnnaple and process 
are constant but the domain is determined by the procedure currently being executed. A process s 
associated subject is therefore variable along the path of execution of the process. 

in a present embodiment of CS 10110, procedures having KOS domain of execution have access to 
objects in KOS. EOS. DBMS, and User domains; procedures having EOS domain of execution have access 
to objects in EOS, DBMS, and User domains; procedures having DBMS domain of execution have access to 
objei^ In DBMS and User domains; and procedures having User domain of ex^ution have access only to 
ob ects in User domain. A user cannot, therefore, obtain access to objects in KOS domain of execution and 
cannot influence CS lOIIO's low level, secure operating system. The user's process "^y'.^TY^'i.*^^" 
execution a procedure having KOS domain of execution. At *is point the process s subject is in the KOS 
domain and the procedure will have access to certain objects m KOS domain. 

In a present embodiment of CS 10110. also described in a later discussion, each object has assoamed 
vwth it an Access Control List (ACU. An ACL contains an Access Control Entry (ACE for each subject haying 
65 access to that object. ACEs specify, for each subject, access rights a subject has with regard to that object 
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There is normaUy no relationship, other than that defined by an object's ACL, between subjects and 
objects. CS 10110, however, supports Extended Type Objects having Extended ACLs wherein a user may 
specifically define which subjects have what acoess lights to the object 

In another embodiment of CS lOIIOi described in a following discussion, access rights are granted on 
^ a dynamic basis. In executing a process, a procedure may call a second procedure and pass an argument to 
the called procedure. The calling procedure will also pass selected access rights to that argument to the 
called procedure. The passed access rights exist only for the duration of the call. 

In the dynamic access embodiment access rights are granted only at the time they are required. In the 
ACL embodiment, access rights are granted upon object creation or upon specie request In either 
embodiment each procedure to which arguments may be passed in a. cross-domain call has associated 
with It an Access Information Array (AIA). A procedure's AIA states what access rights a calling procedure 
(subject) must have before the called procedure can operate on the passed argument CS 10110's 
protection mechanisms compare the calling procedure's access rights to tite rights required by the called 
procedure. This ensures that a calling procedure may not ask a called procedure to do what the calling 
procedure is not allowed to do. Effecth^ely. a calling procedure can pass to a called procedure only the 
access rights held by the calling procedure. * 

Having described the general structure and operation and certain features of CS 101 10, those and other 
features of CS 10110 operation will next be described in greater detaiL 

2» B. Computer System 10110 Information Structures and Mechanisms (Figs. 102, 103, 104, 105) 

CS 10110 corrtains certain information structures and mechanisms to assist in efficient execution of 
processes. These structures and mechanisms may be considered as falling into three general types. The 
first type concerns the processes thennselves, i.e., procedure and data objects comprising a user's process 
or directly related to execution of a user's process. The second type are for management, control, and 

25 execution of processes. These structures are generally ^ared by ail processes active in CS 1 01 1 0. The third 
type are CS 10110 micromachine Information structures and mechanisms. These structures are concerned 
with the ^mal operation of the CS 101 10 micromachine and are private to the CS 10110 micro*machine. 

a. Introduction (Fig. 102) 

30 Referring to Rg. 102, a pictorial representation of CS 10110 (MEM 10112, FU 10120, and EU 10122) is 
shown v/ith certain information structures and mechanisms depicted therein. It should be urKierstood that 
these information structures and mechanisms transcend or "cut across" the boundaries between MEM 
10112, FU 10120, EU 10122, and lOS 10116. Referring to the upper portion of Fig. 103 Proc^ Structures 
10210 contains those information structures and mechanisms most closely concerned with individual 

3S processes, the first and third types of information structures described above. Process Structures 10210 
reside in MEM 10112 and Virtual Processes 10212 include Virtual Processes (VP) 1 through N. Virtual 
Processes 10212 may contain. In a present embodiment of CS 10110, up to 256 VPs, As previous 
described, each VP includes certain objects particular to a single user's process, for example stack objects 
previously described and further described in a following description. Each VP also includes a Process 

40 Object containing certain Information required to execute the process, for example pointers to other 
process information. 

Virtual Processor State Blocks (VPSBs) 10218 include VPSBs containing certain tables and mechanisms 
for managing execirtion of VPs selected for execution by CS 10110. 

A particular VP Is bound Into CS 10110 when a Virtual Process Dispatcher, described in a following 

45 discussion selects that VP as eligible for execution. The selected VPs Process Object as previously 
described, is swapped into a VPSB. VPSBs 10218 may comain, for example 16 or 32 State Blocks so that CS 
10110 may concurrentiy execute to 16 or 32 VPs. When a VP assigned to e VPSB is to be executed, the VP 
is swapped onto the Information structures and mechanisms shown in FU 10120 arul EU 10122. FU Register 
and Stack Mechanism (FURSM) 10214 and EU Register and Stack Mechanism (EURSM) 10216, shown 

so respectively in FU 10120 and EU 10122, comprise register and stack mechanisms used in execution of VPs 
bound to CS 10110. These register and stack mechanisms, as will be discussed below, are also used for 
certain CS 10110 process management functions. Procedure Objects (POs) 10213 -contains Procedure 
Objects (POs) 1 to N of the processes executing in CS 10110. 

Addressing Mechanisms (AM) 10220 are a part of CS 10110's process management system and are 

ss generally associated vmth Computer System 10110 addressing functions as described in following 
discussions. UIO/AON Tables 10222 is a structure for relating UID's and AON's, previously discussed. 
Memory Management Tables 10224 Includes structures for (1) relating AON logical addresses and MEM 
10112 physical addresses; (2) managing MEM 10112's physical address space; (3) managing transfer of 
Information between MEM 10112 and CS lOIIO's backing store (ED 10124} and, (4) acth/ating objects Into 

CO CS 10110; Name Cache (NC) 10226 and Address Translation Cache (ATC) 10228 are acceleration 
mechanisms for storing addressing information relating to the VP currently bound to CS 101 10. NC 10226, 
described further below, contains information relating operand Names to AON addresses. ATC 10228, also 
discussed further below, contains information relating AON addresses to MEM 10112 physical addresses. 
Protection Mechanisms 10230, depicted below AM 10220, include protection Tables 10232 and 

CS Protection Cache (PC) 10234. Protection Tables 10232 contain information regarding access rights to each 
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object active In CS 10110. PC 10234 contains protection information relating to certain objects of the VP 
currently bound to CS 10110. 

Microinstruction Meclianisms 10236, depicted below PM 10230, Includes Micro-code (M Code) Store 
10238r FU (Micro-code) M Code Structure 10240, and EU Micro-code (M Code) Structure 10242. These 
^ structures contain microinstruction mechanisms and tables for interpreting SINs and controlling the 
detailed operation of CS 10110. Micro-instruction Mechanisms 10232 also provide microcode tables and 
mechanisms used, in part, in operation of the low level, secure operating system that manages and 
controls CS 101 ICs physical resources. 

Having thus briefly described certain CS 10110 information structures and mechanisms with the aid of 
Rg. 102, those information structures and mechanisms will next be described in further detail in the order 
mentioned above. In these descriptions It should be noted that, in representation of MEM 10112 shown In 
Rg, 102 and in other figures of following discussions, the addressable memory space of MEM 10112 is 
depicted. Certain portions of MEM 10112 address space have been designated as containing certain 
information structures and mechanisms. These structures and mechanisms have real physical existence in 
MEM 10112, but may vary in both location and volume of MEM 10112 address space they occupy. 
Assigning position of a single, large memory to contain these structures and mechanisms allows these 
structure and mechanisms to be reconfigured as required for most efficient operation of CS 10110. In an 
alternate embodiment, physically separate memories may be used to contain the structures and 
medianisms depicted in MEM 10112, rather than assigned portions of a single memory. 

20 

b. Process Stmcture 10210 (Rgs, 103, 104, 105) 

Referring to Rg. 103, a partial schematic representation of Process Structures 10210 is shown. 
Specifically, Rg. 103 shows a Process (P) 10310 selected for execution, and its associated Procedure 
Objects (POs) in Process Objects (POs) 10213. P 10310 is represented in Fig. 103 as including four procedure 

25 objects in POs 10213. it is to be understood that this representation Is for clarity of presentation; a particular 
P 10310 may include any number of procedure objects, ^so for clarity of presentation, EURSM 1021 6 is not 
shown as EURSM 10216 is similar to FURSM 10214. EURSM 10216 will be described In detail in the 
following detail^ discussons of CS 101 10*$ structure and operation. 

As previously discussed, each process includes certain data and procedure object. As represented in 

30 Rg. 103 for P 10310 the procedure objects reside in POs 10213. The data objects include Static Data Areas 
and stack mechanisms in P 10310. POs, for example KOS Procedure Object (KOSPO) 10318, contain the 
various procedures of the process, each procedure being a sequence of SINs defining an operation to be 
performed in executing the process. As will be described below. Procedure Objects aiso contain certain 
information used in executing the procedures contained therein. Static Data Areas (SOAs) are data objects 

-2S generally reserved for storing data having an existence for the duration of the process. P 10310's stack 
medianisms allow stacking of procedures for procedure calb and returns and for swapping processes in 
and out of JP 10114. Macro-Stacks (MAS) 10328 to 10334 are generally used to store automatic data (data 
generated during execution of a procedure and having an existence for the duration of that procedure). 
Although shown as separate from the stacks In P 10310, the SDAs may be contained with MASs 10328 to 

^ 10334. Secure Stack (SS) 10336 stores, in general, CS 10110 micro-machine state for each procedure called. 
Information stored in SS 10336 allows machine state to be nacovered upon return from a called procedure, 
or when binding (swapping) a VP Into CS 10110. 

As shown in P 10310, each process is structured on a domain basis. A P 10310 may therefore include, 
for each domain, one or more procedure objects containing procedures having that domain as their 

^ domain of execution, an SE>A and an MAS. For example, KOS domain of P 10310 includes KOSPO 10318, 
KOSSDA 10326, and KOSMAS 10334. P 10310's SS 10336 does not reside in any single domain of P 10310, 
but Instead is a stack mechanism belonging to CS 10110 micromachine. 

Having described -die overall structure of a P 10310, the individual Information structures and 
mechanisms of a P 10310 will next be described in greater detail. 

so 

1. Procedure Objects (Rg. 103) 

KOSPO 10318 is typical of CS10110 procedure objects and will be referred to for illustration In the 
following discussion. Major components of KOSPO 10318 are Header 10338, External Entry Descnpter 
(EED) Area 10340, Internal Entry Oescripter (lED) Area 10342, S>Op Code Area 10344, Procedure 
SS Environm^ Descripter (PED) 10348, Name Table (NT) 10350, and Access Information Array (AIA) Area 
10352. 

Header 1 0338 contains certain Information identifying P0 1 0318 and indicating the number of entries in 
EED area 10340, discussed momentarily. 

EED area 10340 and lED area 10342 together contain an Entry Descripter (ED) for each procedure in 
60 KOSPO 10318. KOSPO 10318 Is represented as containing Procedures 1, 2, and 11, of which Procedure 11 
will be used as an example in the present discussion. EDs effectively comprise an index through certain all 
information in KOSP0 10318 can be located. lEDs form an index to alt KOSP0 10318 procedures which may 
be called only from other procedures contained in KOSPO 10318. EEDs form an Index to all KOSPO 10318 
procedures which may be called by procedures external to KOSPO 10318. Externally callable procedures 
6S are distinguished aid, as described in a following discussion of CS 10110's protection mechanisms, in 
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conffrming external calling procedure's access rights. 

Referring to ED 11, ED for procedure 11, three fields are shown therein. Procedure Environment 
Descripter Offset (PEDO) fleid indicates the start, relative to start of KOSPO 10318, of Procedure 1Vs PED in 
PED Area 10348. As will be discussed further beiow, a procedure's PED contains a set of pointers for 

5 locating information used In the execution of that procedure. PED Area 10348 contains a PED for each 
procedure contained in 10318. In the present embodiment of CS 101 10, a single PED may be shared by two 
or more procedures. Cocte Entry Point (CEP) field indicates the start relative to Procedure Base Pointer 
(PBP) which will be discussed below, of Procedure 1 1's SIN Code and SIN Code Area 10344. Finally, ED 1 1's 
Initial Frame Size QFS) field indicates the required Initial Frame Size of the KOSMAS 10334 frame storing 

10 Procedure 11's automatic data. 

PED 11, Procedure 11 's PED In PED Area 10348, contains a set of pointers for locating information used 
in execution of Procedure 11. The first entry in PED 11 is a header containing Information identifying PED 
11. PED 11 's Procedure Base Pointer {PBP> entry is a pointer providing a fixed reference from which other 
information in PO 10318 may be located. In a specific example, Procedure 1 Vs CEP Indicates the location, 

15 relative to PBP, of the start of Procedure 1 1 's S-Op code in S-Op Code Area 10344. As will be described 
further below, PBP is a CS 10110 Architectural Base Pointer {ABP). CS 10110's ASP'S are a set of 
architectural pointers used in CS 101 10 to fadlitate addressing of CS 101 10's address space. PED 1 Vs Static 
Data Pointer (SDP) entry points to data, in PO 10318, specifying certain parameters of P 10310's KOSSDA 
10326. Name Table Pointer (NTP) entry is a pointer indicating the location, in NT 10350, of Name Table 

20 Entry's (NTE's) for Procedure 1 Vs operands, NT 10350 and NTE's will be descnbed in greater detail in the 
following discussion of Computer System lOIIO's Addressing Structure. PED 1 Vs S-lnterpreter Pointer 
(SIP) entry is a pointer, discussed in greater detail in a following discussion of CS 10110's microcode 
structure, pointing to the particular S-lnterpcter (SINT) to be used in interpreting Procedure 11 's SIN Code. 
Referring finally to AIA 10352, AlA 10352 contains, as previously discussed, information pertaining to 

2S access rights required of any external procedure calling a 1 0318 procedure. There is an AIA 10352 entry for 
each PO 10318 procedure which may be called by an external procedure. A particular AIA entry may be 
shared by one or more procedure having an ED in EED Area 10340, Each EED contains certain information, 
not shown for clarity of presentation, indicating that that procedure's corresponding AIA entry must be 
referred to, and the calling procedure's access rights confirmed, whenever that procedure is called. 

30 

2. Stack Mechanism {Rgs. 104, 

As previousiy described, PI 0310*8 stack mechanisms include SS 10336, used in part for storing 
machine state, and MAS's 10328 to 10334, used to store local data generated during execution of P 1031 0's 
procedures. P 10310 is represented as containing an MAS for each CS 10110 domain. In an ahemate 

X embodiment of CS 101 10, a particular P 10310 will include MAS's only for those domains In which that P 
10310 is ex^uiting a procedure. 

Refening to MAS's 10328 to 10334 and SS 10336, P 10310 is represented as having had eleven 
procedure calls. Procedure 0 has called Procedure 1, Procedure 1 has called Procedure 2, and so on. Each 
time a procedure is called, a corresponding stadc frame Is constructed on the MAS of the domain in which 
the called procedure is executed. For example. Procedures 1, 2, and 11 execute in KOS domain; MAS 
frames for Procedures 1, 2, and 11 therefore are placed on KOSMAS 10334. Similarly, Procedures 3 and 9 
execute In EOS domain, so that their stack frames are placed on EOSMAS 10332. Procedures 5 and 6 
execute in DBMS domain, so that thar stack frames are placed on DBMSMAS 10330. Procedures 4, 7, 8, 
and 10 execute in User domain with their stack fram^ being placed on USERMAS 10328. Procedure 11 is 

46 the most recentiy called procedure and procedure 1 Vs stack frame on KOSMAS 10334 is referred to as the 
current frame. Procedure 1 1 is the procedure which is currently being executed when VP 1 031 0 is bound to 
CS 10110. 

SS 10336, which is a stack mechanism of CS 10110 micromachine, contains a frame for each oiF 
Procedures 1 to 11. Each SS 10336 frame contains, in part, CS 10110 operating state for its corresponding 
so procedure. 

Referring to Fig. 104, a schematic r^resentation of a typical MAS, for example KOSMAS 10334, is 
shown. KOSMAS 10334 Includes Stack Header 10410 and a Frame 10412 for each procedure on KOSMAS 
10334. Each Frame 10412 includes a Frame Header 10414. and may contain a Linkage Pointer Block 10416, a 
Local Pointer Block 10418, and a Local (Autt^matic) Data Block 10420. 
SS KOSMAS 10334 Stack Header 10410 contains at least the following information: 

(1) an offset, relative to Stack Header 10410, indicating the location of Frame Header 10414 of the first 
frame on KOSMAS 10334; 

(2) a Stack Top Offset (STO) Indicating location, relative to start of KOSMAS 10334, of the top of 
KOSMAS 10334; top of KOSMAS 10334 Is indicated by pointer STO pointing to the top of the last entry of 

eo Procedure 11 Frame 10412's Local Data Block 10420; 

(3) an offset relative to start of KOSMAS 10334, Indicating location of Frame Header 10414 of the 
cun^nt top frame of KOSMAS 10334; in Rg. 104 this offeet is represented by Frame Pointer <FP), an ABP 
discussed further below; 

(4) the VP 1031 0*s UID; 

^ (5) a UID Pointer indicating location of certain domain environment information, described further in a 
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following discussion; 

(6) a signaller pointer indicating the location of certain routines for handling certain CS 10110 operating 
system faults; 

(7) a UIO pointer indicating location of KOSSDA 10326; and 

sr iS] a frame label sequencer containing pointers to headers of frames In other domains; these pointers 
are used in executing non-local go*to operations. 

KOSMAS 10334 Stack Header 10410 thereby contains information for locating certain Important points 
in KOSMAS 10334*5 structure, and for locating certain Information pertinent to executing procedures in 
KOS domain. 

w Each i=rame Header 10414 contains at least the following information: 

(1) offsets, relative to the Frame Header 10414, indicating the locations of Frame Headers 10414 of the 
previous and next frames of KOSMAS 1 0334; 

(2) an offset, relative to the Frame Header 1041 4, indicating the location of the top of that Frame 1 041 2; 

(3) information indicating the number of passed arguments contained in that Frame 10412; 

fs (4) a dynamic back pointer, in UID/Offset format, to the previous Frame 1041 2 if that previous Frame 
10412 resides in another domain; 

(5) a UID/Offset pointer to tiie environmental descripter of the procedure calling that procedure; 
{6} a frame label sequence containing information indicating the locations of other Frame Headers 
10414 in KOSMAS 10334; this information is used to locate other frames in KOSWIAS 10334 tor the purpose 

20 of executing local go-to operations. Frame Headers 10414 tiiereby contain Information for locating certain 
important points in KOSiWAS 10334 structure, and certain data pertinent to executing die associated 
procedures. In addition. Frame Headers 10414, in combination with Stack Header 10410, contain 
Infomiation for linking tiie actuation records of each VP 10310 MAS, and for linking togetiier the activation 
records of the individual MAS's. 

25 Unkage Pointer Blocks 10416 contain pointers to arguments passed from a calling procedure to the 
called procedure. For example, Unkage Pointer Block 10416 of Procedure 11's Frame 10412 will contain 
pointers to arguments passed to Procedure 11 from Procedure 10. The use of linkage pointers in CS1 01 lO's 
addressing structure will be discussed further in a following discussion of CS 10110's Addressing 
Structure. Local Data Pointer Blocks 10418 contain pointers to certain of the associated procedure's local 

30 data. Indicated in Rg. 104 is a pointer. Frame Pointer (FP), pointing between top most Frame 10412's 
Linkage Pointer Blodn 10416 and Local Dau Pointer Block 10418. FP, described further in following 
discussions, is an ABP to MAS Frame 10412 of the process's current procedure. 

Each Frame 10412's Local (Automatic) Data Block 10420 contains certain of tiie associated procedure's 
automatic data. 

35 As descrited above, at each procedure call a MAS frame is constructed on top of the MAS of the 
domain in which the called procedure is executed. For example, when Procedure 10 calls Procedure lie 
Frame Header 10414 for Procedure 1 1 is constructed and placed on KOSMAS 10334. Procedure 1 1's linkage 
pointers are then generated, and placed in Procedure 1 1's Unkage Pointer Block 10416. Next Procedure 1 Vs 
local pointers are generated and pieced in Procedure 11's Local Pointer Block 10418. Rnally, Procedure 11's 

40 local data is placed in Procedure IVs Local Data Block 10420. During this operation, USERMX^ 10328's 
frame label sequence is updated to include an entry pointing to Procedure IVs Frame Header 10414, 
KOSMAS 10334's Stack Header 10410 is updated with respect to STO to the new top of KOSMAS 10334. 
Procedure 2's Frame Header 10414 is updated with respect to offset to Frame Header 10414 of Procedure 1 1 
Frame 10412, and with respect to frame label sequence indicating location of Procedure 11's Frame Header 

45 10414. As Procedure 11 is then the current procedure, FP is updated to a point between Unkage Pointer 
Block 10416 and Local Pointer Block 10418 of Procedure 1 1 's Frame 1 0412. Also, as will be discussed below, 
a new frame is constaicted on SS 1 0336 or Procedure 11 . CS 101 10 will then proceed to execute Procedure 
11. During execution of Procedure 11, any further local data generated may be placed on the top of 
Procedure IVs Local Data Block 10420. The top of stack offset information in Procedure 11's Frame Header 

so 10414 and in KOSMAS 10334 Stack Header 10410 will be updated accordingly. 

MAS's 10328 to 10334 thereby provide a per domain stack mechanism for storing data pertaining to 
indhndua! procedures, thus allowing stacking of procedures without loss of this data. Although structured 
on a domain basis, MAS's 10328 to 10334 comprise a unified logical stack structure threaded togetiier 
through information stored in MAS stack and frame headers. 

^ As described above and previously, SS 10336 is a CS 10110 micromachine stack structure for storing, 
in part, CS 10110 micromachine state for each stacked VP 10310 procedure. Referring to Fig. 105, a partial 
schematic representation of a SS 10336 Stack Frame 10510 is shown. SS 10336 Stack Header 10512 and 
Frame Headers 10514 contain Information similar to that in MAS Stack Headers 10410 and Frame Headers 
10414. Again, the information contained therein locates certain points within SS 10336 structure, and 

eo tiireads togetiier SS 10336 witii MAS's 10328 to 10334. 

SS 10336 Stack Frame 10510 contains certain Information used by the CS 10110 micromachine in 
executing the VP 10212 procedure with which this frame is associated. Procedure Pointer Block 10516 
contains certain pointers Including ABPs, used by CS 10110 micromachine in locating infomiatlon within 
VP 10310'8 information structures. Micro-Routine Frames IMRFs) 10518 together comprise Micro-Routine 

^ Stack (MRS) 10520 within each SS 10336 Stack Frame 10510. MRS Stack 10520 Is associated whh the 



33 



EP 0 067 5S6 B1 



internal operation of CS 10110 microroutines executed during execution of the VP 10212 procedure 
associated with the Stack Frame 10S10. SS 10336 is thus a dual function CS 10110 micromachine stack. 
Pointer Block 10516 entries effectively define an interface between CS 101 10 micromachtne and the current 
procedure of the current process. MRS 10520 comprise a stack mechanism for the internal operations of CS 
^ 10110 micromachine. 

Having briefly described Virtual Processes 10212, FURSM 10214 will be described next As stated 
above, EURSM 10216 is similar in operation to FUBSM 10214 and will be described in following detailed 
descriptions of CS 10110 structure and operation. 

^° a RJRSM 10214 {Rg. 103) 

Referring again to Rg. 103, FURSM 10214 indudes CS 10110 micromachine information structures 
used internally to CS 10110 micromachine in executing the procedures of a P 10310. When a VP, for 
example P 10310 Js to be executed, certain information regarding that VP is transferred from the Virtual 
Processes 10212 to FURSM 1 0214 for use in executing that procedure, tn this respect, FURSM 10214 may be 
regarded as an acceleration mechanism for the current Virtual Process 10212. 

FURSM 10214 indudes General Register Rte (GRF) 10354, Micro Stack Pointer Register Mechanism 
(MISPR) 10356, and Return Control Word Stack (RCWS) 103K. GRF 10354 includes Global Registers <GRs) 
10360 and Stack Registers (SRs) 10362. GRs 103^ include Architectural Base Registers (ABRs) 10364 and 
Micro-Control Registers (MCRs) 10366. Stack Registers 10362 Include Micro-Stack (MIS) 10368 and Monitor 

^ Stack (MOS) 10370. 

Referring first to GRF 1 0354, and assuming for example that Procedure 1 1 of P 1031 0 is currently being 
executed, GRF 10354 primarily contains certain pointers to P 10310 data used in execution of Procedure 11. 
As previously disussed, CS 10110's addres^ng structure includes certain Architectural Base Pointers 
(ABPs) for each procedure. ABPs provide a framework for excessing CS 10110's address space. The ABPs 
of each procedure inchide a Frame Pointer (FP). a Procedure Base Pointer (PBP), and a Static Data Pointer 
(STP). As discussed above with reference to KOSPO 10318, these ABPs reside in the procedure's PEDs, 
When a procedure Is called, these ASP'S are transferred from that procedure's PED to ABR's 10364 and 
reside therein for the duration of that procedure. As indicated in Fig. 103, FP points between Linkage 
Pointer Block 10416 and Local pointer Blocks 10418 of Procedure IVs Frame 10412 on KC^MAS 10334. PBP 
points to the reference point from whidi the elements of KOSP0 1031 8 are located. SDP points to ICOSSDA 
10326. If Procedure 11 calls, for example, a Procedure 12, Procedure 11's ABPs will be transferred onto 
Procedure Pointer Block 10516 of SS 10336 Stack Frame 10510 for Procedure 11. Upon return to Procedure 
11, Procedure 11's ABPs will be transferred from Procedure Pointer Block 10516 to ABR's 10364 and 
execution of Procedure 1 1 resumed. 

^ MCRs 10336 contain certain pointers used by CS 10110 micromachine in executing Procedure 11. CS 
10110 micromachine pointers indicated In Fig. 103 include Program Counter (PC), Name Table Pointer 
(NTP), S-lnterpr^r Pointer (SIP), Secure Stack Pointer (SSP), and Secure Stack Top Offset (SSTO). NTP and 
SIP have been previously described with reference to KOSPO 10318 and reside in KOSP0 1031& NTP and 
SIP are transferred Into MCR's 10366 at start of execution of Procedure 1 1. PC, as indicated in Rg. 103, is a 

^ pointer to the Procedure 11 SIN currently being executed by CS 10110. PC is initially generated from 
Procedure 11's PBP and CEP and is thereafter incremented by CS 101 10 micromachine as Procedure H's 
SIN sequences are executed SSP and SSTO are, as described In a following discussion, generated from 
information contained in SS 10336's Stack Header 10512 and Frame Headers 10514. As indicated In Rg. 103 
SSP points to start of SS 10336 while SSTO indicates the oirrent top frame on SS 10336, whether 

^ Procedure Pointer Block 10516 or a MRF 10518 of MRS 10520, by Indicating an offset relative to SSP. if 
Procedure 11 calls a subsequent procedure, the contents of MCR's 10366 are transferred into Procedure 
11's Procedure Pointer Block 10516 on SS 10336, and are returned to MCR's 10366 upon return to 
Procedure 11. 

Registers 10360 contain further pointers, described in following detailed discussions of CS 10110 

so operation, and certain registers which may be used to contain the current procedure's local data. 

Referring now to Stadc Registers 10362, MIS 10^ is an upward extension, or acceleration, of MRS 
10520 of the current procedure. As previously stated, MRS 10520 is used by CS 10110 micromachine in 
executing certain microroutines during execution of a particular procedure. MIS 10368 enhances tiie 
effidency of CS 101 10 micromachine in executing these microroutines by accelerating certain most recent 

& MRFs 10518 of that procedure's MRS 10520 into FU 10120. MIS 10368 may contain, for example, up to ti^ 
eight most recent MRFs 10518 of the current procedures MRS 10520. As various microroutines are called or 
returned from« MRS 10520 MRFs 10518 are transferred accordingly between SS 10336 and MIS 10368 so 
that MIS 10368 ahvays contains at least the top MRF 10518 of MRS 10520, and at most eight MRf=s 10518 of 
MRS 10520. MISPR 10356 is a CS 10110 mteromachtne mechanism for maintaining MIS 10368. MISPR 

» 10356 contains a Current Pointer, a Previous Pointer, and a Bottom Pointer. Current Poirrter points to the 
top-most MRF 10518 on MIS 10368. Previous Pointer points to the previous MRF 10518 on MIS 10368, and 
Bottom Pointer points to the bottom-most MRF 10518 on MIS 103®. MISPR 10356's Current Previous and 
Bottom Pointers are updated as MRFs 10518 are transferred between SS 10336 and MIS 10368. If Procedure 
n calls a subsequent procedure, all Procedurell MRFs 10518 are transferred from MIS 10368 to Procedure 

€5 11's MRS 10520 on SS 10336. Upon return to Procedure 11, up to seven of Procedure 11's MRFs 10518 
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microSnlforhandUng fault orerrorcondltions-Thesemlcroroutin^^^^ 

MOS 10370 resides entirely in FM 10120 and is not an extension of a stacic residing in a P 10310 m MbM 

5 101 12. MOS 10370 may contain, for example, eight frames. If more than eight successnre fault or error 
conditions occur, this is regarded as a major failure of CS 10110. Control ^^^^^^JI^O "^^^ ?I 
transferred to DP 10118. As will be described in a following discussion, diagnostic programs in DP 10118 
may then be used to diagnose and locate the CS 10110 faults or errors. In other embod.mente of CS 101 10 
MOS 10370 may contain more or fewer stadi frames, depending upon the degree of self diagnosis and 
correction capability desired for CS 10110. u.k mic m'Msa a 

RCWS 1M58 is a two-part stack mechanism. A first part operates in paraltei whh M S 10368 and a 
second^rt operates in parallel with MOS 10370. As previously described. CS 10110.8 a mwrocode 
controlled system. RCWS is a stack for storing the current microinstruction being executed »n^ (S101 10 
micromachine when the current procedure is interrupted by a fault " 

'« subsequent procedure is called. That portion of RCWS 10358 associated with MS 103M COTtero an e^^ 
for each MRF 10518 residing in IWIIS 10368. These RCWS 10^8 entnes are trarerfOTtid bWw^^ 103M 
and MIS 10368 in parallel with their associated MRFs 10518. When resident in SS 1^36. these RWf 
entoies are stored within their associated MRFs 10518. That portion of RCWS 10358 aaociated wrth MOT 
1037Tsimilarly operates in parallel with MOS 10370 and. like MOS 10370. is not an extension of an MEM 

20 10112 resident stack. . „„«j4„ 

In summary, each process active in CS 101 10 exists as a separate, complete, and self-contained enbty. 
or Virtual Process, and is stnicturally organized on a domain basis. Each Virtual Process includes, besides 
pn«edure and data objects, a set of MAS's for storing local data of that P™««2|^^ P/fi^'^.^^^to^fT^^'^^^ 
Soc^ also includes a CS 101 10 micromachine stack, SS 10336. for stonng CS 101 10 micromachine stete 

» pertaining to each stacked procedure of the Virtual Process. CS lOIIO^J^wornadiine <ncludesa set of 
Smalu>n structures, register 10360, MIS 10368. MOS 10370, and RCWS 1l»58 used by CS 10110 
mfc^STachine in execLtin? the Virtual Process's procedun«. Certain of these CS 10110 "I'ci^h.ne 
information structures are shared with the currently executing Virtual ^'^^^^^ 
acceleration mechanisms for the current Virtual Process.whileothersarecompletely internal to CS 10110 

30 "^^""^'^^^ of CS 10110 is that each process' macrostacks and secure stack resides in MEM 
10112. CS 10110*8 macrostack and secure stacks are therefore effecth/ely unlimited j" depth. 

VrteiHJther of CS 10110 micromachine is the use of GRF 10354. GRF 10354 is. in an 

embodiment of CS 101 10, a unitary register an^y containing for example, 256 registers. ^'^f}PJf'^°'*\?' 

3S SiSSions. of GRF 10354 are dedicated to. respectively, GRs 10360. MIS 10368. and (WOSI 0370. 1>;e 
capacities of GR 10360, MIS 10368. and MOS 10370. may therefore be adjusted as required for optimum^ 
10110 efficiency, by reassignment of GRF 10354's address space, in other embodiments of CS 10110. GRs 
10360. MIS 10368. and MOS 10370 may be JmP'ememod a functioMlly wparate rs^.^era aja^ 

H^ng briefly described *e structure and operation of Process Structures 10210, VP Stats Block 10218 

4V will be described next below. 

C. Virtual Processor State Blocks and Virtual Process Creation (Rg. 102) 

Rrferring again to Flo. 102. VP State Blocks 10218 is used in management and control of processes. VP 
State Blocks 10218 contains a VP State Block for eacti Virtual Process (VP) selected for e^eajtion by CS 
4S 10110. Each such VP State Block contains at least the follovwng information: (1) the state, or identification 

number of a VP; j . , x^i. uo 

(2) entries Identifying the particular principle and particular process ottne vi*; 

(3) an AON painter to that VP's secure stack (e.g.. SS 10336>; 

(4) the AON's of that VP's MAS stack objects (e.g.. MAS's 10328 to 10334); and, 

so (5) certain information used by CSIOIIffs VP Management System. . 

The information contained in each VP State Block thereby defines the current state of the asociated VP. 
A Process is loaded into CS 10110 by building a primitive access record and loading this access record 
Into CS 10110 to appear as an already existing VP. A VP is created by creating a Process Object, including 
pointers to macro- and secure-stack objects created for that VP, micromachine state entries, and a pomter 
SS to the user's program. CS 101 10's KOS then generates Macro- and Secure-Stack Objecte with headers for 
that process and, as described further below, loads protection information regarding that process objecu 
into protection Structures 10230. CS 101 10's KOS then copies tills primithre machine state record into a 
vacant VPSB selected by CS 101 10's VP Manager, thus binding the newly created VP into CS 10110. At that 
time a KOS Initialiajer procedure completes creation of the VP for example by calling in the user's program 
so through a compiler. The newly creatd VP may then be executed by CS 10110. . ^ _ 

Having briefly described VP State Blocks 10218 and creation of a VP. CS 101 10's Addressmg Structures 
10220 will be decribed next below. 
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□.Addressing Structure 10220 (Rgs, 103, 106, 107, 108) 

1. Objects, Uicys, AON's, Names, and Physical Addresses {Rg. 106) 

As previously described, the data space accessible to CS 1 01 1 0 is divided into segments, or containers, 
referred to as objects. In an embodiment of CS 10110, the addressable data space of each object has a 
s capacity of 2^ bits of information and is structured into 2^° pages with each page containing 2" bits of 
information. 

Refernng to Rg. 106A. a schematic representation of CS lOllO's addressing structure is shown. Each 
object created for use in, or by operation of, a CS 10110 is pemnanently assigned a unique Identifier (UID). 
An object's UID allows an object to be uniquely identified and located at any future point in time. Each UIO 

fo is an 80 bit number, so that the total addressable space of all CS 101 ID'S includes 2^ objects wherein each 
object may contain up to 2^ bits of Infonmation. As indicated in Rg. 1 06, each 80 bit UID is comprised of 32 
bits of logical Allocation Unit identlfi^ (LAUID) and 48 bits of Object Serial Number <0SN). LAUIDs are 
associated with Individual CS 10110 systems. LAUIDs identify the particular CS 10110 system generating a 
particular object Each LAUtD is comprised of a Logical Allocation Unit Group Number (LAUGN) and a 

15 Logical Allocation Unit Serial Number (LAUSN). LAUGNs are assigned to indhndual CS 101 10 systems and 
may be guaranteed to be unique to a particular system. A particular system may, however, be assigned 
more than one LAUGN so that there may be a time varying mapping between LAUGNs and CS 10110 
systems. LAUSNs are assigned within a particular system and, white LAUSNs may be unique within a 
particular system, LAUSNs need not be unique between systOTis and need not map onto the physical 

20 structure of a particular system. 

OSNs are assodated with individual objects created by an LAU and are generated by an Architectural 
Clock in each CS 10110. Architectura! clock is defined as a 64 bit binary number representing increasing 
time. Least significant bit of architectural clock represents incremerrts of 600 picoseconds, and most 
significant bit represents increments of 127 years. In the present embodiment of CS 10110, certain most 

25 slgnfftcant arKl least significam bits of architectural clock time are disregarded as generally not required 
practice. Time indicated by architectural dock is measured relative to an arbitrary, fixed point in time. This 
point in time is the same for all CS 101 10s which will ever be constructed. All CS 10110s in existence will 
therefore indicate the same architectural dock time and all UIDs generated will have a common basis. The 
use of an archhectural dock for generation of OSNs is advantageous in that it avoids the possibility of 

30 acddental duplication of OSNs rf a CSC 10110 fails and is subsequently reinitiated. 

As stated above, each object generated by or for use in a CS 10110 is uniquely identified by its 
assodated UID. By appending Offset <0) and Length (L) information to an object's UID, a UID logical 
address is generated which may be used to locate particular segments of data redding in a particular 
object As indicated in Rg. 106, 0 and L fields of a UID logical address are each 32 bits. O and L fields can 

35 therefore indicate any particular bit out of 2^"^ bits, in an object and thus allow bit granular addressing of 
information in objects. 

As indicated in Rg. 1(^ and as previously described, each object active in CS 10110 is assigned a short 
temporary unique identifier valid only within JP 10114 and referred to as an Active Object Number (AON). 
8«:ause fewer objects may be active in a CS 101 1 0 than may exist In a CS 101 10's address space, AON's 

40 are, in the presem embodiment of CS 10110, 14 bits in length. A particular CS 10110 may therefore contain 
up to 2^^ active objects. An object's AON is used within JP 10114 in place of that object's UID. For example, 
as discussed above with reference to process structures 10210, a procedure's FP points to start of that 
procedure's frame on its process' MAS. When that FP is residing in SS 10336, it is expressed as a UID. 
When that procedure is to be executed, FP is transferred from SS 10336 to ABR's 10364 and is translated 

4S into the corresponding AON, Similarly, when that procedure is stacked, FP is retumed to SS 103% and in 
doing so is translated into the corresponding UID. Again, a particular data segment in an object may be 
addressed by means of an AON logica] address compridng the object's AON plus assodated 32 bit Offset 
(0) and Length (L) fields. 

Each operand appearing in a process is assigned a Name and all references to a process's operands are 

so through those assigned Names. As indicated in Rg. 106B, in the present embodiment of CS 10110 each 
Name is an 8, 1 2, or 1 6 bit numt>er. All Names within a particular process will be of the same length. As will 
be described in a following discussion, Nannes appearing during execution of a process may be resolved, 
through a procedure's Name Table 10^ or through Name Cache 10226, to an AON logical address. As 
described below, an AON logical address corresponding to an operand Name may then be evaluated to a 

55 MEM 10112 physical address to locate the operand referred to. 

The evaluation of AON logical addresses to MEM 10112 physical addresses is represented in Rg. 106C 
An AON logical address's L field is not involved in evaluation of an AON logical address to a physical 
address andr for purposes of darity of presentation, is therefore not r^resented In Rg. 106C AON lexical 
address L field is to be understood to be appended to the addresses represented in the various steps of the 

eo evaluation procedure shown in Rg. 106C. 

As described above, objects are 2^ bits stnjctured imo 2^^ pages with each page containing a 2^^ tuts of 
data. MEM 10112 is similariy physically structured into frames with, in the present embodiment of CS 
10110, each frame containing 2^^ bits of data. In other embodiments of CS 101 10, both pages and frames 
may be of different sizes but the translation of AON logical addresses to MEM 1 01 12 physical addresses will 

es be similar to that described momentarily. 
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An AON logical address O field was previously described as a 32 bit number representing the start, 
relative to start of the object, of the addressed data segment within the object The 18 most significant bits 
of O field represent the number (P) of the page within the object upon which the first bit of the addressed 
data occurs. The 14 least significant bits of O field represent the offset (Op), relative to the start of the page, 
within that page of the first bit of the addressed data. AON logical address O field may therefore, as 
indicated In Fig. 106C, be divided into an 18 bit page (P) field and a 14 bit offset wKhin page <0p) field. Since, 
as described above, MEM 10112 physical frame size is equal to object page size, AON logical address Op 
field may be used directly as an offset withfn frame fO,) field of the physical address. As will be described 
below, an AON logical address AON and P fields may then be related to the frame number (FN) of the MEM 
10112 frame in which that page resides, through Addressing Mechanisms 10220, 

Having briefly described the relationships between UIDs, UID Logical Addresses, Names, AONs. AON 
Logical Addresses, and MEM 10112 Physical Addresses, Addressing Mechanisois 10220 will be described 
next below. 

2. Addressing Mechanisms 10220 (Rg, 107) 

Referring to Fig. 107, a schematic representation of Computer System 10110's Addressing 
Mechanisms 10220 is shown. As previously described. Addressing Mechanisms 10220 comprise UID/AON 
Tables 10222, Memory Management Tables 10224, Name Cache 10226, and Address Translation Unh 
10228. 

UID/AON Tables 10222 relate each object's UID to its assigned AON and include AOT Hash Table 
(AOTHT) 10710. Active Object Table (AOT) 10712, and Active Object Table Annex (AOTA) 10714. 

An AON corresponding to a particular UID is determined through AOTHT 10710. The UID is hashed to 
provide a UID Index into AOTHT 10710, which then provides the corresponding AON. AOTHT 10710 is 
effectively an acceleration mechanism of AOT 1 0712 to, as just described, pro\nde rapid translation of UIDs 
to AONs. AONs are used as indexes into AOT 10712, which provides a corresponding AOT Entry (AOTE). 
An AOTE as described in following detailed discussions of CS 101 10, includes, among other information, 
the UID corresponding to the AON indexing the AOTE. In addition to providing translation between AONs 
and UIDs, the UID of an AOTE may be compared to an original UID to determine the correctness of an AON 
from AOTHT 10710. 

Associated with AOT 10712 is AOTA 10714. AOTA 10714 is an extension of AOT 10712 and contains 
certain information pertaining to active objects, for example the domain of execution of each active 
procedure object 

Having briefly described CS 10110's nfiechanism for relating UIDs and AONs, CS 10110's mechanism 
for resohring operand Names to AON logical addresses will be described next below. 

3. Name Resolution (Figs. 103. 108) 

Referring first to Fig. 103, each procedure object in a VP, for sample KOSP0 10318 in VP 1031 0, was 
described as containing a Name Table <NT) 10350. Each NT 10350 contains a Name Table Entry (NTE) for 
each operand whose Name appears its procedure. Each NTE contains a description of how to resoh^ the 
corresponding Name to an AON Logical Address^ including fetch mode information, type of data referred 
to by that Name, and length of the data segment refen^d to. 

Referring to Rg, 108, a representation of an NTE is shown. As indicated, this NTE contains seven 
information fields: Flag, Base (B), Predi^facement (PR), Length (L), CMspfacement (D), Index (I), and Inter- 
element Spadng (lES). Rag Reld, in part, contains information describing how the remaining fields of the 
NTE are to be interpreted, type of information referred to by the NTE, and how that information is to 
handled when fetched from MEM 10112. L Held, as previously described, indicates length, or number of 
bits in, the data segment Functions of the other NTE fields will be described during the followina 
discussions. 

In a present embodiment of CS 101 10, there are five types of NTE: (1 ) base (B) is not a Name, address 
resduticm is not Indirect; (2) B is not a Name, address resolution is indirect; (3) B is a Name, address 
resolution Is Indirect; (4) B Is a Name, address resolution is indirect. A fifth type is an NTE selecting a 
particular element from an array of elements. These five types of NTE and their resolution will be described 
below, in the order mentioned. 

In the first type, B Is not a Name and address resolution is not indirect, B Field specifies an ABR 10364 
containing an AON plus offset (AON/O) Pointer. The contents of D Field are added to the O Field of this 
pointer, and the result is the AON Logical Address of the operand. In the second type, B is not a Name and 
address resolution is indirect B Field again specifies an ABR 10364 containing an AON/0 pointer. The 
contents of PR Held are added to the 0 Field of the AON/O pointer to provide an AON Logical Address of a 
Base Pointer. The Base Pointer AON Logical Address is evaluated, as described below, and the Base Pointer 
fetched from MEM 1 01 12. The contents of D Field a re added to the O Field of the Base Pointer and the result 
is the AON Logical Address of the operand. 

NTE types 3 and 4 con-espond, respectively to NTE types 1 and 2 and are resolved in the same manner 
except that B Field contains a Name. The B Reld Name is resolved through another NTE to obtain an AON/ 
0 pointer which is used in place of the ABR 10364 pointers referred to in discussion of types 1 and 2. 

The fifth type of NTE is used in references to elements of an array. These array NTEs are resolved in the 
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same manner as ^fTE types 1 through 4 above to provide an AON Logical Address of the start of the array. I 
and lES Raids provide additional information to locate a particular element in the array. 1 Reld is always 
Name whic^ Is resolved to obtain an operand value representing the particular element in the array. lES 
Reld provides information regarding spacing between dements of the array, that is the number of bits 
^ between adjacent element of the array. lES Reld may contain the actual lES value, or it may contain a Name 
which is resolved to an AON Logical Address leading to the Inter-element spacing value. The \ and 1E5 
values, obtained by resolving the i and lES Fields as just described, are multiplied together to determine the 
offset relative to the start of the array, of the particular element referred to by the NTE This within array 
offset is added to the 0 Field of the AON Logical Address of the start of the array to provide the AON Logical 
Address of the element 

in the current embodiment of CS 10110, certain NTE fields, for example B, and Flag fields, always 
contain literals. Certain other fields, for example, lES, D, PRE, and L fields, may contain either literals or 
names to be resolved. Yet other fields, for example 1 field, always contain names which must be resoh^ed. 

Passing of arguments from a calling procedure to a called procedure has been previously discussed 
with reference to Virtual Processes 1021 2 above, and more specifically with regard to MAS's 10328 to 10334 
of VP 10310. Passing of arguments is accomplished through the callir^g and called procedure's Name 
Tables 10350. In illustration, a procedure W(a, b, c) may v«sh to pass arguments a, b, and c to procedure 
X(u, V, w), where arguments, v and w correspond to arguments a, b, and c At compilation, NTEs are 
generated for arguments a, b, and c in procedure Ws procedure object, and NTEs are generated for 

^ arguments u, v and w in Procedure X's procedure object Procedure X's NTEs for u, v, and w are 
constructed to resolve to point to pointers in Linkage Pointer Block 10416 of Procedure X's Frame 10412 in 
MAS. To pass arguments a, b, and c from Procedure W to Procedure X, the NTEs of arguments a, b, and c 
are resolved to AON Logical Addresses (i.e., AON/0 form). Arguments a. b, and c's AON Logical Addresses 
are then translated to corresponding UID addresses which are placed in Procedure X's Linkage Pointer 

^ Block 10416 at those places pointed to by Procedure X's NTEs for u, v, and w. When Procedure X is 
executed, the resolution of Procedure X's NTEs for u, v, and w will be r^olved to locate the pointers, in 
Procedure X's Linkage Pointer Block 10416 to arguments a, b, and c When arguments are passed in this 
manner, the data type and length information are obtained from the called procedure's NTEs, rather than 
the callirig procedure's NTEs. This allows the calling procedure to pass only a portion of, for example, 

^ arguments a, b, or c, to the called procedure and thus may be regarded as a feature of CS 10110's 
protection mechanisms. 

Having briefly described resolution of Names to AON/Offset addresses, and having previously 
d^cribed translation of UID addresses to AON addresses, the evaluation of AON addresses to MEM 10112 
physical addresses will be described next below. 

35 

4. Evaluation of AON Addresses to Physical Addresses (Fig. 107} 

Referring again to Rg. 107, a partial schematic representation of CS 10110's Memory Management 
Table 10224 is shown. Memory Hash Table (MHT) 10716 and Memory Frame Table {MFT) 10718 are 
concerned vyith translation of AON addresses into MEM 10112 physical addresses and will be discussed 
^ first Working Set Matrix (WSM) 10720 and Virtual Memory Manager Request Queue (VMMRQJ 10722 are 
concerned with management of MEM 101 irs available physical address base and v^ll be discussed 
second. Active Object Request Queue (AORQ) 10728 and ijoglcal Allocation UnH Directory (LAUD) 10730 
are concerned with locating inactive oi^ects and management of which objects are active in CS 10110 and 
will be discussed last 

Translation of AON/O Logical Addresses to MEM 10112 physical addresses was previously discussed 
with reference to Rg. 106C. As stated in that discussion, objects are divided into pages. Correspondingly, 
the AON/0 Logical Address' 0 Fidd is divided into an 18 bit page number (P) Held and a 14 bit offset within 
a page (Op) Reld. MEM 101 12 is stnjctured into frames, each of which In the present embodiment of CS 
10110 is equal to a page of an object An AON/O address' Op Reld may tiierefore be used directly as an 
so offset witiiin frame (Of) of the corresponding physical address. The AON and P fields of an AON address 
must« however, be translated into a MEM 10112 frame represented by a corresponding Frame Number 
(FN). 

Referring now to Rg. 107, an AON address' AON and P Relds are "hashed" to generate an MHT index 
which is used as an index Into MHT 10716. Briefly, ''hashing" is a method of indexing, or locating, 

55 information in a table wherein indexes to the information are generated from the information itself through 
a "hashing function". A hashing function maps each piece of Information to the corresponding index 
generated from it through the hashing function. MHT 10716 then provides ttie corresponding FN of the 
MEM 10112 frame In which that page is stored. FNs are used as indexes Into MFC 10718, which contains, 
for each FN, an entry describing the page stored in that frame. This information includes the AON and P of 

60 the page stored in that MEM 101 12 frame. An FN from MHT 1071 6 may therefore be used as an Index Into 
MFT 10718 and the resulting AON/P of MFT 10718 compared to the original AON/P to confirm the 
correctness of the FN obtained from MHT 10716. MHT 10710 is an effectively acceleration mechanism of 
MFT 10718 to provide rapid translation of AON address to MEM 10112 physical addresses. 

MFT 10718 also stores "used" and "modified" information for each page in MEM 10112. This 

^ information indicates which page frames stored therein have been used and which have been nru>dlfied. 
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This information is used by CS 101 10 In determining which frames may be deleted from MEM 10112. or are 
free, when pages are to be written into MEM 10112 from backing store {ED 1 0124). For example, if a page's 
modified bit indicates that that page has not been written into, it Is not necessary to write that page back 
into backing store when it is deleted from MEM 10112; instead, that page may be simply erased. 

s Referring finally to ATU 10228, ATU 10228 is an acceleration mechanism for MHT 10716. AON/0 
addresses arc used directly, without hashing, as indexes into ATU 1 0228 and ATU 1 0228 correctly provides 
corresponding FN and 0 outputs. A CS 101 10 mechanism, described In a following detailed discussion of 
CS 101 10 operation, continually updates the contents of ATU 10228so that ATU 10228 contain theFN'sand 
Op (0,) of the pages most frequently referenced by the current process. If ATU 10228 does not contain a 

10 corresponding entry for a given AON Input an ATU fault occurs and the FN and 0 infomiatiori may be 
obtained directly from MHT 10716. 

Referring now to WSM 10720 and VMMRQ 10722, as previously stated these mechanisms are 
concemed with the management of MEM 101 12's available address space. For example, if MHT 10716 and 
MFT 10718 do not contain an entry for a page referenced by the current procedure, an MHT/MFT fault 

IS occurs and the reference page must be fetched from backing store (ED 10124) and read into MEM 101 12. 
WSM 10720 contains an entry for each page resident in MEM 101 12. These entries are accessed by indexes 
comprising the Virtual Processor Number (VPN) of the virtual process making a page reference and the P of 
the page being referenced. Each WSM 10720 entiy contains 2 bits stating whether the particular page is 
part of a VP's working set, that Is, used by that VP, and whether that page has been referenced by that VP. 

20 This Information, together with tfie infomiation contained in that MFT 10718 entnes descnbed above, is 
used by CS 10110's Virtual Memory Manager (VMM) In transferring pages into and out of MEM 10112. 

CS 101 10's VMM maintains VMMRQ 10722, which Is used by VMM to control transfer of pages into and 
out of MEM 1 01 1 2. VMMRQ 10722 includes Virtual Memory Request Counter (VMRC) 10724 and a Queue of 
Virtual Memory Request Entries (VMREs) 10726. As will be discussed momentarily, VMRC 10724 tracks the 

25 number of currently outstanding request for pages. Each VMRE 10726 describes a particular page which 
has been requested. Upon occurrence of a MHT/MFT (or page) fault, VMRC 10724 is incremented, which 
initiates operation of CS 10110's VMM, and a VMRE 10726 is placed in the queue. Each VMRE 10726 
comprises the VPN of the process requesting the page and the AON/0 of the page requested. At this time, 
the VP making the request is swapped out of JP 101 14 and another VP bound to JP 10114. VMM allocates 

30 MEM 1 01 1 2 frame to contain the requested page, u^ng the previously descrtoed information In MFT 10718 
and WSM 10720 to select this frame. In doing so, VMM may discard a page currently resident in MEM 10112 
for example, on the baas of b«ng the oidest page, an unused page, or an unmodified page which does not 
have to be written back into backing store. VMM then requests an I/O operation to transfer the requested 
page into the frame selected by the VMM. While the I/O operation is proceeding, VMM generates new 

3S entries in MHT 10716 and MFT 10718 for the requested page, cleans the frame in MEM 101 12 which is to be 
occupied by that page, and suspends operation. lOS 10116 will proceed to execute the I/O operation and 
writes the requested page directly into MEM 10112 in the frame specified by VMM. lOS 1 01 16 then notifies 
CS 10110's VMM that the page now resides in memory and can be referenced. At some later time, that VP 
requesting that page will resume execution and repeat that reference. Going first to ATU 10228. that VP ^11 

40 take an ATU 10228 fault since VP 10212 has not yet been updated to contain that page. The VP will then go 
to MHT 10716 and MFT 10718 for the rec^ired information and, concurrently, WSM 10720 and ATU 10228 
will be updated. ^ . — 

In regard to the above operations, each VP active in CS 10110 is assigned a Page Fault Frequency Time 
Factor (PFFT) which is used by CS 101 10's VMM to adjust that VP's woricing set so that the Interval between 

45 successive page faults for that VP lies in an optimum time range. This assists in ensuring CS 10110's VMM 
is operating most efficiently and allows CS 10110's VMM to be tuned as required. 

The above discussions have assumed that the page being referenced, whether from a UID/O address, 
an AON/0 address, or a Name, is resident In an object active in CS 10110. While an object need not have a 
page fn MEM 10112 to be active, the object must be active to have a page in MEM 10112. A VP, however, 

SO may reference a page in an object not active in CS 101 10. If such a reference is made, the object must be 
made active in CS 10110 before the page can be brought into MEM 101 12. The result is an operation similar 
to the page fault operation described above. CS 10110 mainUins an Active Object Manager (AOM), 
including Active Object Request Queue (AORQ) 10728, which are similar in operation to CS 10110's VMM 
and VMMRQ 10722. CS 10110's AOM and AORQ 10728 operate in conjunction with AOTHT 10710 and AOT 

55 10712 to locate inactive objecte and make them active by assigning them AON's and generating entries for 
them in AOTHT 10710, AOT 10712, and ACTA 10714. ^ 

Before a particular object can be made active in CS 10110, it must first be located in backing store (ED 
10124). All objects on backing store are located through a Logical Allocation Unit Directory (LAUD) 10730, 
which is resident in backing store. /Vn LAUD 10730 contains entries for each object accessible to the 

&} particular CS 101 10. Each LAUD 10730 entry contains the information necessary to generate an AOT 10712 
entry for that object. An LAUD 10730 is accessed through a UID/0 address contained in CS 101 10's VMM. A 
reference to an LAUD 10730 results In MEM 101 12 frames being assigned to that LAUD 10730, and LAUD 
10730 being transferred Into MEM 101 12. If an LAUD 10730 entry exists for the referenced inactive object, 
the LAUD 10730 entry is transferred into AOT 10712. At the next reference to a page in that object, AOT 

es 10712 will provide the AON for that object but, because the page has not yet been transferred into MEM 
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10112, a page fault will occur. This page fault will be handled In the manner described above and the 
referenced page transferred into MEM 10112. 

Having briefly described the structure and operation of CS 101 10's Addressing Structure, including the 
relationship between UlDs, Names, AONs, and Physical Addresses and the nnechanisnis by which CS 1 01 1 0 
manages the available address space of MEM 10112« CS 10110's protection structures will be described 
next bdow. 

E. CS 10110 Protection Mechanisms (Rg. 109) 

Referring to Rg. 109, a schematic representation of Protection Mechanisms 10230 is shown. Protection 
Tables 10232 include Active Primitive Access Matrbc (APAM) 10910, Active Subject Number Hash Table 
(ASNKT) 10912, and Active Subject Table (AST) 10914. Those portions of Protection Mechanism 10230 
resident in RJ 10120 include ASN Register 10916 and Protection Cache (PC) 10234. 

As previously discussed, access rights to objects are arbitrated on the basis of subjects. A subject has 
been defined as a particular combination of a principle. Process, and Domain (PPD), each of which is 
identified by a corresponding UID. Each object has associated with ft an Access Control Ust (ACL) 10918 
containing an ACL Entry (ACLE) for each subject having access rights to that object. • 

When an object becomes acth/e in CS 101 10 (i.e., is assigned an AON) each ACLE In that object's ACL 
10918 IS written into APAM 10910. Concurrently, each subject having access rights to that object, and for 
which there is an ACLE in that objecfs ACL 10918, IS assigned an Active Subject Number (ASN). These 
ASNs are written into ASNHT 10912 and their cofTosponding PPDs are written into AST 10914. 
Subsequently, the ASN of any subject requesting access to that object is obtained by hashing the PPD of 
tfiat subject to obtain a PPD index into ASNHT 10912. ASNHT 10912 will in turn provide a corresponding 
ASN, An ASN may be used as an index into AST 10914. AST W14 will provide the corresponding PPD, 
which nr>ay be compared to an original PPD to confirni the accuracy of the ASN. 

As described above, APAM 10910 corrtains an ACL 10918 for each object active in CS 101 10. The access 
nghts of any particular active subject to a particular active object are determined by using that subject's 
ASN and that object's AON as indexes into APAM 10910. APAM 10910 in turn provides a 4 bit output 
defining v^ether that subjea has Read (R) Write (W) or Execute (E) rights with respect to that object, and 
whether that particular entry is Valid (V). 

ASN Register 1091 6 and PC 10234 are effectively acceleration nnechanisms of Protection Tables 1023Z 
ASN Register 1 091 6 stores the ASN of a currently active subject while PC 10234 stores certain access right 
infbrtTiation for objects being used by the current process. PC 10234 entries are Indexed by ASNs from ASN 
register 10916 and by a mode input from JP 10114. Mbde input defines whether the current procedure 
intends to read, write, or execute with respect to a particular object having an entry in PC 10234. Upon 
recatving ASN and mode inputs, PC 10234 provides a go/nogo output indicating whether that subject has 
the access rights required to oeecute the intended operation with respect to that object 

In addlticm to the above mechanism, each procedure to which arguments may be passed in a cross- 
(tomain call has associated v«th it an Access Informaticn Array <AIA) 1 0352, as discussed with reference to 
Virtual Processes 10212, A procedure's AIA 10352 states what access rights a calling procedure (subject) 
must have to a particular ot^ect (argument) before the called procedure can operate on the passed 
argument CS 101 10's protection mechanisms compare the calling procedures access rights to the rights 
required by the called procedure. This insures the calling procedure nnay not ask a called procedure to do 
what the caUing procedure is not allowed to do. Effectively, a calling procedure can pass to a called 
procedure only the access rights held by the calling procedure. 

finally, PC 10234, APAM lOTIO, or AST 1 0914 faults <l.e., misses) are handled in the same manner as 
descnbed above wth reference to page faults in discussion of CS 1 01 10's Addres^ng Mechanisms 1 0220. 
As such, the handling of protection misses will not be discussed further at this point 

Having briefly described structure and operation of CS 101 10's Protection Mechanisms 10230, CS 
10110*8 Micro-Instruction Mechanisms 10236 will be described next below. 

F. CS 10110 Micro-Instruction Mechanism (Rg. 110) 

As prewously described, CS 10110 is a multiple language machine. Each program written in a high 
level user language fe compiled into a corresponding S-Unguage program containing instructions 
expressed as SINs. CS 10110 provides a set, or dialect, of microcode Instructions, referred to as S- 
Interpreters (SINTs) for each S-Language. SINTs interpret SINs and provide corresponding sequences of 
microinstructions for detailed control of CS 10110- 

Referring to Rg. 110, a partial schematic representation of CS 101 10's Micro-Instruction Mechanisms 
10236 Is shown. At system initialization all CS 10110 microcode, including SINTs and all machine assist 
microcode, is transferred from backing store to Micro-Code Control Store (mCCS) 10238 in MEM 10112, 
The Micro-Code is then transferred from mCCS 10238 to FU Micro-Code Structure (FUmC) 10240 and Eli 
Micro-Code Structure (EUmC) 10242. EUmC 10242 is similar in structure and operation to FUmC 10240 and 
thus will be described in following detailed descriptions of CS 101 10's structure and operation. Similarly, 
CS 10110 machine assist microcode will be described in following detailed discussions. The present 
discussion will concern CS 10110's S-lnterpreter mechanisms. 

CS 10110's S-lnterpreters (SINTs) are loaded Into S-lnterprat Table (SITT) 11012, which is represented 
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in Rg. 1 10 as containing S-lnterpreters 1 to N. Each SIT contains one or more sequences of micro-code; 
each sequence of microcode corresponds to a particular SIN In that S-Language dialect. S-lnterpreter 
Dispatch Table (SDT) 11010 contains S-lnterpreter Dispatchers (SDs) 1 to N. There is one SDfor each SINT 
in snr 11012, and thus a SD for each S-Language dialect Each SD comprises a set of pointers. Each pol nter 

5 in a particular SD con^esponds to a particular SIN of that SD's dialect and points to the corresponding 
sequence of microinstructions for Interpreting that SIN in that dialecf s SIT in SITT 1 101 2. In illustration, as 
previously discussed when a particular procedure is being executed the SIP for that procedure is 
transferred Into one of mCR's 10365. That SIP points to the start of the SD for the SIT which is to be used to 
interpret the SINs of that procedure. In Rg. 1 10, the SIP in mCRs 10366 is shown as pointing to the start of 
SD2. Each S-Op appearing during execution of that procedure is an offset, relative to the start of the 
selected SD, pointing to a corresponding SD pointer. That SD pointer in turn points to the corresponding 
sequence of microinstructions for interpreting that SIN in the corresponding SIT in SITT 11012. As wl« t>e 
described in following discussions, once the start of a microcode sequence for interpreting an SIN has been 
selected; CS 101 1 0 micromachine then proceeds to sequentially call the microinstructions of that sequence 

IS from SITT 1 1012 and use those microinstructions to control operation of CS 10110. 

G. Summary of Certain CS 101 10 Features and Alternate Embodiments 

The above Introductory Oveiview has described the overall structure and operation and certain 
features of CS 101. that is, CS 10110. The above Introduction has further described the structure and 

20 operation and further features of CS 10110 and, in particular, the physical Implementation and operation of 
CS 10110's information, control, and addressing mechanisms. Certain of these CS 10110 features are 
summarized next below to briefly state the basic concepts of these features as implemented in CS 1 01 10. In 
addition, possible alternate embodiments of certain of these concepts are described. 

first CS 10110 is comprised of a plurality of independentiy operating processors, each processor 

25 having a separate microinstruction control. In the present embodiment of CS 10110, these processors 
include RJ 10120, EU 10122, MEM 10112 and lOS 10116. Other such independently operating processors, 
.for example, special arfthmetic processors such as an array processor, or multiple FU 10120's, may be 
added to the present CS 10110. 

In this regard, MEM 101 12 is a muhiport processor having one or more separate and independent ports 

30 to each processor in CS 10110. All communications between CS lOllCs processors are through MEM 
101 1 2, so that MEM 10112 operates as the central communications node of CS 10110, as well as performing 
memory operations. Further separate and Independent ports may be added to MEM 10112 as further 
processors are added to CS 10110. CS 10110 may therefore be described as comprised of a plurality of 
separate, independent processors, each having a separate microlnstfxiction control and having a separate 

as and independent port to a central oommunications and memory node which in itself is an independ»it 
prt>cessor having a separate and independent microinstruction control. As will be further described in a 
following detailed description of MEM 10112, MEM 10112itself is comprised of a plurality of independently 
operating processors, each performing memory related operations and each having a separate 
microinstruction control. Coordination of operations between CS 10110's processors is achieved by 

40 passing "messages" between the processors, for example, SOPs and descriptors. 

CS 10110's addressing mechanisms are based, first, upon UID addressing of objects. That is, all 
information generated for use in or by operation of a CS 10110, for example, data and procedures, is 
structured into objects and each object is assigned a pennanent UID. Each UID is unique within a particular 
CS 101 10 and between all CS 101 1 0's and is permanently associated with a particular object The use of UID 

4S addressing provides a permanent unique addressing means which Is common to all CS 10110's, and to 
other computer systems using CS 10110's UID addressing. 

Effectively, UID addressing means that the address (or memory) space of a particular CS 10110 
includes the address space of all systems, for example disc drives or other CS 10110s, to which that 
particular CS 10110 has access, UID addressing allows any process in any CS 10110 to obtain access to any 

so object in any CS 101 10 to which it has physical access, for example, another CS 101 10 on the other side of 
the world. This access is constrained only by CS lOIIO's protection mechanism. In alternate embodiments 
of CS 10110, certain UIDs may be set aside for use only within a particular CS 10110 and may be unique 
only within that particular CS 101 10. These reserved UIDs would, however, be a limited group known to all 
CS 10110 systems as not having uniqueness between systems, so that the unique object addressing 

55 capability of CS 10110's UID addressing is preserved. 

As previously stated, AONs and physical descriptors are presently used for addressing within a CS 
10110, effectwely as shortened UIDs. In alternate embodiments of CS 10110, otiier forms of AONs may be 
used, or AONs may be discarded entirely and UIDs used for addressing within as well as between CS 
10110s. 

60 CS 10110's addressing mechanisms are also based upon the use of descriptors within and between CS 
10110s. 

Each descriptor includes an AON or UID field to identify a particular object, an offset field to specify a 
bit granular offset whhin the object and a length field to specify a particular number of bits beginning at the 
specified offset. Descriptors may also include a type, or format field identifying the particular format of the 
£5 data referred to by the descriptor. Physical descriptors are used for addressing MEM 10112 and, in this 
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case, the AON or UID field is replaced by a frame number field referring to a physical location in MEM 
1011Z 

As stated above, descn'ptors are used for addressing within and between the separate, independent 
processors (FU 10120/EU 10122, MEM 10112,. and lOS 10116) comprising CS 10110, thereby providing 
^ common, system wide bit granular addressing which includes format information. In particular, MEM 
10112 responds to the type Information fields of descriptors by performing formatting operations to 
provide requestors with data In the format specified by the requestor in the descriptor. MEM 10112 also 
accepts data In a format specified in a descriptor and reformats that data into a format most efficiently used 
by MEM 10112 to store the data. 

As previously described, all operands are referred to In CS 10110 by Names wherein all Names within a 
particular S-Language dialect are of a uniform, fixed size and format A K value specifying Name size is 
provided to FU 10120, at each change in S-Language dialect and is used by FU 10120 in parsing Names 
from the instruction stream. In an alternate embodiment of CS 101 10, all Names are the same size in all S- 
Language dialects, so that K values, and the associated circuitry in FU 10120's parser, are not required. 

Finally, in descriptions of CS 101 1 0's use of SOPs, FU 10120's microinstruction circuitry was described 
as storing one or more S-Interpreters. S-lnterpreters are sets of sequences of microinstructions for 
Interpreting the SOPs of various S-Language dialects and providing corresponding sequences of 
microinstructions to control CS 10110. in an alternate embodiment of CS 10110. these S-lnterpreters (SITT 
11012] would be stored in MEM 10112. FU 10120 would receive SOPs from the instruction stream and, 
^ using one or more S-lnterpreter Base Pointers <that is, architectural base pointers pointing to the SFTT 
11012 in MEM 10112), address the SfTT 11012 stored in MEM 10112. MEM 10112 would respond by 
providing, from the SITT 11012 in MEM 10112, sequences of microinstructions to be used directly in 
controlling CS 10110. Alternately, the SITT 11012 in MEM 10112 could provide conventional instructions 
usable by a conventional CPU, for example, Fortran or machine language instructions. This, for example, 
^ would allow FU 10120 to be replaced by a conventional CPU, such as a Data General Corporation Ecfipse®. 

Having briefly summarized certain features of CS 101 1 0, and altemate embodiments of certain of these 
features, the stnjcture and operation of CS 10110 wlU be described in detail below. 

_ 2. DETAILED DESCRIPTION OF CS 10110 MAJOR SUBSYSTEMS 

^ (Rgs,201— 206,207— 274) 

Having previously described the overall structure and operation of CS 10110, the structure and 
operation of CS 101 ICs major subsystems will next be indhddually described in further detail As 
previous discussed, CS 101 Ws major subsystems are, in the order in which they will be described, MEM 
10112, FU 10120, EU 10122, lOS 10116, and DP 10118. Indhrfdual block diagrams of MEM 10112, FU 10120, 

^ EU 10122, lOS 10116, and DP 10118 are shown in, respectively, Rgures 201 through 205. Rgures 201 
tiirough 205 may be assembled as^ shown In Rg. 206 to constaict a more detailed block diagram of CS 
101 10 corresponding to that shown in Rg. 101. For the purposes of the following descriptions, it is assumed 
that Rgs, 201 through 205 have be«i assembled as shown m Rg. 206 to construct such a block diagram. 
Further diagrams will be presented in following descriptions as required to convey structure and operation 

<o of CS 101 10 to one of ordinary skill in the art 

As previously described, MEM 10112 Is an intellfgent priortizing memory having separate and 
independent ports MIO 10128 and MJP 10140 to, respectively, IDS 10116 and JP 10114. MEM 10112 is 
shared by and is accessible to both JP 10114 and lOS 10116 and is the primary memory of CS 10110. In 
addition, MEM 10112 is the primary path for information transferred between the external world {throuqh 

45 lOS 10116) and JP 10114. 

As will be described further below, MEM 10112 is a two-level memory providing fast access to data 
stored therein. MEM 10112 first level is comprised of a large set of random access arrays and MEM 10112 
second level is comprised of a high speed cache whose operation is generally transparent to memory 
users, that is JP 10114 and lOS 10116. Information stored in MEM 10112, in either level, appears to be bit 

SO addressable to both JP 10114 and ICS 10116. In addition, MEM 101 12 presents simple interfaces to both JP 
10114 iand ICS 101 16. Due to a high degree of pipe lining (concurrent and overlapping memory operations) 
MEM 10112 Interface to both JP 10114 and IDS 10116 appear as if each HP 10114and lOS 10116 have full 
access to MEM 101 1Z This feature allows data transfer rates of up to, for example, 63.6 megabytes per 
second from MEM 10112 and 50 megabytes per second to MEM 10112. 

ss In the following descriptions, certain terminology used on those descriptions vwll be introduced first 
followed by description of MEM 10112 physical organization. Then MEM 10112 port structures vinll be 
described, followed by descriptions of MEM 10112's control organization and control flow. Next, MEM 
10112's Interfaces to JP 10114 and lOS 10116 will be described. Following these overall d^riptions the 
major logical structures of MEM 10112 will be individually described, starting at MEM 10112's interfaces to 

eo JP I0114and lOS lOIIBand proceeding inwardly to MEM 10112'8 first <or bulU level of data stored. Rnally, 
certain features of MEM 10112 microcode control structure will be described. 

A. MEM 10112 (Rgs. 201, 20$, 207—237) 
a. Terminology 

€S Certain terms are used throughout the following descriptions and are defined here below for reference ' 
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by the reader. 

A word is 32 bits of data 
A byte Is 8 bits of data 
A biodc is 128 bits of data (that is, 4 words). 
* * A block IS always aligned on a block boundary, that is the low order 7 bits of logical or physical address 
are zero (see Chapter 1, Sections A.f and D. Descriptions of CS 10110 Addressing). 

The term aligned refers to the staning bit address of a data item relative to certain address boundaries. 
A starting bit address is block aligned when the low order 7 bits of starting bit address are equal to zero, 
that Is the starting bit address falls on a boundary between adjacent blocks. A word align starting bit 
address means that the low order 5 bits of starting bit address are zero, the starting bit address points to a 
boundary between adjacent words. A byte aligned starting bit address means that the low order 3 bits of 
starting bit address are zero, the starting bit address points to a boundary between adjacent bytes. 

Bit granular data has a starting bit address falling wi^in a byte, but not on a byte boundary, or the 
address is aligned on a byte boundary but the length of the data is bit granular, that is not a multiple of 8 
'5 bits. 

b. MEM 10112 Physical Structure (Fig, 201 ^ 

Referring to Fig. 201, a partial block diagram of MEM 10112 is shown. Msjor functional units, of MEM 
10112 are Main Store Bank (MSB) 20110, including Memory Arrays (MA's) 20112, Bank Controller (BC) 

20 201 14, Memory Cache (MC) 201 16, including Bypass Write RIe {BYF} 201 18, Reld Isolation Unit (RU) 20120, 
and Memory Interface Controller <MIC) 20122. 

MSB 20110 comprises MEM 101 12'8 first or bulk level of storage. MSB 201 10 may include from one to, 
for example, 16 MA 201 12's. Each MA 20112 may have a storage capacity, for example, 256 K-byte, 512 K- 
byte, 1 M-byte, or 2 M-faytes of storage capacity. As will be described further below, MA 201 12's of different 

zs capacities may be used together in MSB 20110. Each MA 20112 has a data input connected in parallel to 
Write Data (WD) Bus 20124 and a data output connected in parallel to Read Data (RD) Bus 20126. MA's 
201 12 also have control and address ports connected In parallel to address and control (ADCTL) Bus 20128. 
In particular. Data Inputs 20124 of Memory Aixays 201 12 are connected In parallel to Write Data <WD) Bus 
20126, and Data Outputs 20128 of Memory Arrays 20112 are connected in parallel to Read Data (RD) Bus 

JO 20130. Control Address Ports 20132 of Memory Arrays 20112 are connected in parallel to Address and 
Control (ADCTL) Bus 20134. 

Data Output ^136 of Bank Controller 201 14 Is connected to WD Bus 20126 and Data Input 20138 of BC 
20114 Is connected to RD Bus 20130. Control and Address Port 20140 of BC 20114 is connected to ADCTL 
Bus 20134. BC 201 14's Data Input 20142 is connected to MC 201 16's Data Ou^ 20144 through Store Back 

3S Data (SBD) Bus 20146. BC 20114's Store Back Address Input 20148 Is connected to MC 201 16 Store Back 
AcMress Output 20180 through Store Back Address (SBA) Bus 20152. BC 20114's Read Data Output 20154 is 
connected to MC 20116*8 Read Data Input 20156 through Read Data Out (RDO) Bus 20158. BC 20114's 
Control Port 20160 is connected to Memory Control (MCNTL) Bus 20164. 

MC 20116 has Output 20166 connected to MfO Bus 10131 through MiO Port 10128, and Port 20168 

40 connected to MOD Bus 10144 through MJP Port 10140. Control Port 20170 of MC 201 16 is connected to 
MCNTL Bus 20164, Input 20172 of BYF 20118 is connected to lOM Bus 10130 through MIO Port 10128, and 
Output 20176 is connected to SBD Bus 20146 through Bypass Write In (BWI) Bus 20178, 

Rnally, FlU 20120 has an Output 20180 and an Input 20182 connected to, respectively, MIO Bus 10129 
and lOM Bus 10130 through MIO Port 101^ Input 20184 and Port 20186 are connected to, respectively, 

46 JPD Bus 10142 and MOD Bus 10144 through MJP Port 10140. Control Port 20188 is connected to MCNTL 
Bus 20164. Referring finally to MIC 20122, MIC 20122 has Control Port 20190 and Input 20192 connected to, 
respectively, lOMC Bus 10131 and lOM Bus 10130 through MIO Port 10128. Control Port 20194 and Input 
20196 are connected, respectively, to JPMC Bus 10147 and Physical Descriptor (PD) Bus 10146 through MJP 
Port 10140. Control Port 20198 is connected to MCNTL Bus 20164. 

so 

c. MEM 10112 General Operation 

Referring first to MEM 10112's interface to lOS 10116, this interface includes MIO Bus 10129, lOM Bus 
10130, and lOMC Bus 10131. Read and Write Addresses and data to be written into MEM 10112 are 
transferred from lOS 10116 to MEM 10112 through lOM Bus 10130. Data read from MEM 10112 Is 

55 transfen-ed to lOS 101 16 through MIO Bus 10129, lOMC 10131 is a Bi-directional Control bus between MEM 
10112 and lOS 10116 and, as described further below, transfers control signals between MEM 10112 and 
lOS 10116 to control transfer of data between MEM 10112 end lOS 10116. 

MEM 101 12's Interface to JP 10114 is MJP Port 10140 and Includes JPD Bus 10142, MOD Bus 10144, PD 
Bus 10146, and JPMC Bus 10147. Physical descriptors, that is MEM 10112 physical read and write 

$0 addresses, are transferred from JP 1 01 14 to MEM 101 1 2 through PD Bus 1 0146. S Ops, that is sequences of 
S Instructions and operand names, are transferred from MEM 10112 to JP 10114 through MOD Bus 10144 
while data to be written into MEM 101 1 2 from JP 101 14 is transferred from JP 101 14 to MEM 101 12 through 
JPD Bus 10142. JPMC Bus 10147 Is a By-directional Control bus for transferring command and control 
signals between MEM 10112 and JP 10114 for controlling transfer of data between MEM 10112 and JP 

es 10114. As will be described further below, MJP Port 10140, and in particular MOD Bus 10144 and PD Bus 
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10146, is generally physically organized as a single port that operates as a dual port In a first case, MJP Port 
10140 operates as a Job Processor Instruction (Jl) Port for transferring S Ops from MEM 101 1 2 to JP 101 14. 
In a second case, MOD 10144 and PD 10146 operate as a Job Processor Operand (JO) Port for transfer of 
operands, from MEM 10112to JP 1011 4« while JPO Bus 10142 and PD Bus transfer operands from JP 10114 
« to MEM 10112, 

Referring to MSB 201 1 0, MSB 201 10 contains MEM 101 1 2's first, or bulk, level of storage capacity. MSB ' 
20110 may contain from one to, for example, 16 MA's 20112, Each MA 20112 contains a dynamic, random 
access memory array and may have a storage capacity of, for example 256 Kilo-bytes, 512 Kilo-bytes, 1 
Mega-bytes, or 2 Mega-bytes. MEM 101 12 may therefore have a physical capacity of up to, for example, 16 
Mega-bytes of bulk storage. As will be described further below. MA 201 12*3 of different capacity may be 
used together in MSB 201 10, for example, four 2 Mega-byte MA 20112's and four 1 Megabyte MA 20112's. 

BC 201 14 controls operation of MA's 201 12 and is the path for transfer of data to and from MA's 201 12, 
In addition, BC 20114 performs error detection and correction on data transferred into and out of MA's 
20112, refreshes data stored in MA's 20112, and, during a refresh operations, performs error detection and 
correction of data stored in MA's 20112. 

MC 20116 comprises MEM 1011 2's second, or cache, level of storage capacity and contains, for 
example 8 Kilo-^jytes of h*^h speed memory. MC 20116, including BYF 20118, is also the path for data 
transfer between MSB 201 10 (through BC 201 14) and JP 101 14 and lOS 101 16, In general, ail read and write 
operations between JP 10114and lOS 10116 are through MC20116. JOS 10116 may, however, perform read 
and write operations of complete blocks by-passing MC ^1 1 6. Block write operations from lOS 1 01 1 6 are 
accomplished through BYF 20118 while block read operations are peribrmed through a data transfer path 
internal to MC 20116 and shown and described below. All read and write operations between MEM 10112 
and JP 10114, however, must be performed through the cache intemal to MC 201 16, as will be shown and 
described further below. 

^ As also shown and described below, RU 20120 includes write data registers for receiving data to be 
written Into MEM 10112 from JP 10114 and lOS 10116, and circuitry for manipulating data read from MSB 
20110 so that MEM 10112 appears as a bit addressable memory, RU 20120, in addition to providing bit 
addre^bility of MEM 10112, performs right and left alignment of data, zero fill of data, sign extension 
operations, and other data manipulation operations described further below. In performing these data 

^ manipulation operations on data read from MEM 10112 to JP 10114, MOD Bus 10144 Is used as a data path 
intamal to MEM 10112 for transfemng of data from MC 20116 to FlU 20120, and from RU 20120 to MC 
20116. That is, data to be transferred to JP 10114 is read from MC 20116, transferred through MOD Bus 
ia44 to HU 20120, manipulated by RU 20120, and transferred from RU 20120 to JP 101 14 through MOD 
Bus 10144. 

SS MIC 20122 contains circuitry controlling operation of MEM 10112 and, in particular, conUols MEM 
10112^8 interface witii JP 10114 and lOS 10116. MIC 20122 receh/es MEM 10112 read and write request that 
is read and write addresses through PD Bus 10146 and lOM Bus 10130 and control signals through JPMC 
Bus 10147 and lOMC Bus 10131, and provides control signals to BC 20114, MC 20116, and RU 20120 
through MCNTL Bus 20164. 

40 Having described the overall structure and operation of MEM 10112, the structure and operation of 
MEM 10112*5 Port, MIO Port 10128, and MJP Port 10140, will be described next, followed by descriptions of 
MEM 10112's control structure and the control and flow of MEM 10112 read and write requests. 

d. MEM 10112 Port Structure 

45 MEM 10112 port structure Is designed to provide a simple interface to JP 10114 and lOS 10116. While 
providing fast and flexible operation in servicing MEM 10112 read and write requests from JP 10114 and 
lOS 101 1 6. In this regard, MEM 101 1 2, as will be described further below, may handle up to 4 read and write 
requests concurrently and up to, for example, a 63.6 M-byte per second data rate. In addition MEM 101 12 Is 
capable of performing bit granular addressing, block read and write operations, and data manipulations, 

50 such as alignment and filling, to enable JP 10114 and lOS 10116 to operate most efficientiy. 

MEM 10112 effectively services requests from three ports. These ports are MIO Port 10128 to lOS 
101 18. hereafter referred to as 10 Port and Jl and JO Ports, described above, to JP 101 14. These three ports 
share the entire address base of MEM 10112, but ICS 101 16, for example, may be limited from making full 
use of MEM 10112's address space. Each port has a different set of allowed operations. For example, JO 

55 Port can use a bit granular addresses but can reference only 32 bits of data on each request Jl Port can 
make read requests only to word align 32 bit data items. 10 Port may reference bit granular data, and, as 
described further bdow, may read or write up to 1 6 bytes on each read or write request. The characteristics 
of each of these ports will be discussed next below. 

60 1. 10 Port Characteristics 

103 101 1 6 may access MEM 101 1 2 in either of two modes. The first mode is block transfers by-passing 
or through the cache in MC 201 16, and the second is non-block transfer through the cache and MC 201 16. 

Block by-passes may occur for both read and write operations. A read or write operation is eligible for a 
block by-pass if the data is on block boundaries, is 16 bytes long, and the read or write request is not 
€5 accompanied by a control signal indicating that an encache (load into MC 201 16's cache) operation is to be 
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performed. A by-pass operation takes place only if the block address, that is the physical address of the 
block in MEM 10112 does not address a currently encached block, that is the block is not present in MC 
20116's cache. If the block Is encached in MC 20^^&s cache, the read or write transfer is to MC 2011^8 
Cfiche. 

5 Partial block references, that is non-ftill block transfers will go through MC 20116's cache. If a cache 
miss occurs, that is the reference data is not present In MC 201 16's cache, MEM 101 12's control structures 
transfer the data to or from MSB 201 10 and update MC 201 1 6's cache. It should be noted that partial blocks 
. may be as short as one byte, or up to 15 bytes long. A starting byte address may be anywhere within a 
block, but the partial block's length may not cross a block boundary. 

w Bit length transfers, that is transfers of data items having a length of 1 to 1 6 bits and not a multiple of a 
byte, or where address is not on a byte boundary, go through MC 20116's cache. These operetions may 
cross byte, word, or block boundaries but may not cross page boundaries. These specific operations 
requested by 10 port determines whether a read or write request is a partial block or bit length transfer. 

fs 2. JO Port Characteristics 

All read or write requests from JO Port must go through MC 201 16's cache; by-pass operations may 
not be performed. The data transferred between MEM 101 12 and JP 101 14 is always 32 bits in length but, of 
the 32 bits passed^ from zero to 32 bits may be valid data. JP 101 14 determines the location of valid data 
within the 32 bits by referring to certain RU specification bits provided as part of the read or write request. 

20 As will be described further below, RU specification bits, and other control bits, are provided to MIC 20122 
by JP 10114 through JPMC Bus 10147 when each read or write request is made. 

While MEM 10112 does not perform block by-pass operations to JP 10114, MEM 10112 may perfomia 
cache read-through operation. Such operations occur on a JP 10114 read request wherein the. requested 
data Is not present In MC 20116's cache, the JP 10114 read request is for a full word, which is word 

26 aligned, MEM 10112's Load Manager, discussed below, transfers the requested data directly to JP 10114 
while concurrently loading the requested data Into MC 20116's cache. This operation is referred to as a 
"hand-off" operation. These operations may also be performed by tO Port for 16 bit haK words aligned on 
the right hand half word of a 32 bit word, or if a full block is handed left and loaded Into MC 201 16's cache. 

30 3* Jl Port Characteristics 

Ail Jl Port requests are satisfied through MC 20116's cache; MEM 10112 does not perfonn by-pass 
operations to Jl Port Jl Port requests are always read requests for full-word aligned words and are handed 
off, as described above, if a cache miss occurs. In most other respects, Jl Port requests are similar to JO 
Port requests. . 

35 Having described the overall structure and operation of MEM 101 12, including MEM 1 01 12'$ Input and 
output ports to JP 10114 and lOS 10116, MEM 10112's control structure will be described next below. 

e. MEM 10112 Control Structure and Operation {Rg. 207) 

Referring to Rg. 207, a more detailed blodc diagram of MIC 201 16 is shown. Rg. 207 will be referred to 
40 in conjunction with Rg. 201 In the following discussion of MEM 10112's control structure. 

1. MEM 10112 Control Structure 

Referring first to Fig. 207, MCNTL Bus 20164 is represented as including MCNTL-BC Bus 20164A, 
MCNTL-MC Bus 20164B, and MCNTL-RU Bus 201 64C. Buses 20164Ar 20164B, and 20164C are branches of 
4S MCmi Bus 201 64 connected to, respectively, BC 201 1 4, MC 201 16, and HU 20120, Also represerrted in Rg. 
207 are PD Bus 10146 and JPMC Bus 10147 to JP 101 14. and lOM Bus 10130 and lOMC Bus 10131 to lOS 
10116. 

JO Port AddfBSS Register (JOPAR) 20710 and Jl Port Address Register (JIPAR) 20712 have inputs 

connected from PD Bus 10146. lO Port Address Register <IOPAR) 20714 has an input connected from lOM 
50 Bus 10130. Port Control Logic (PC) 20716 has a bi-directional input/outputs connected from JPC 10147 and 

lOMC Bus 10131. By-pass Read/Write Control Logic (BR/WC) 20718 has a bidirectional input/output 

connected from lOMC Bus 10131. 

Outputs of JOPAR 20710, JIPAR 20712, and lOPAR 20714 are connected to inputs of Port Request 

Multiplexer (PRMUX) 20720 through, respectively. Buses 20732, 20734. 20736. PRMUX 20720's output in 
s$ turn is connected to Bus 20738. Branches of Bus 20738 are connected to Inputs of Load Pointers (LP) 20724. 

Miss Control (MISSC) 20726. and Request Manager (RM) 20722, and to Buses MCNTL-MC 201 64B and 

MCNTL-RU 201 64C. 

Outputs of PC 20716 are connected to inputs of JOPAR 20710, JIPAR 20712, lOPAR 20714, PRMUX 
20720, and LP 20724 through Bus 20738. Bus 20740 is connected between an Input^output of PC 20716 and 
eo in input/output of RM 20722. 

An output of BR/WC* 20718 is connected to MCIMTL-MC Bus 201 64B through Bus 20742. Inputs of BR/ 
WC 20718 are connected from outputs of RM 20722 and Read Queue (RQ) 20728 through, respeaively, 
Buses 20744 and 20746. 

RM 20722 has outputs connected to MCNTL-BC Bus 20164A, MCNTL-RU Bus 20164C, and input of 
65 MISSC 20726, and an Input of LP 20724 through, respectively, Buses 20748, 20^ 20752, and 20754. 
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MISSC 20726's output is connected to MCNTL-BC Bus 20164A. Outputs of LP 20724 are connected to 
MCNTL-MC Bus 201 64B and to an input of LM 20730 through, respectively, Buses 20756 and 2075a RQ 
20728's input is connected from MCNTL-MC Bus 20164B through Bus 2Q760 and RQ 20728 has outputs 
^ connected to an input of LP 20724, through Bus 20762, and as previously described to an input of BR/WC 
20718 through Bus 20746. Finally, LM 20730's output is connected to MCNTL-MC Bus 201648 through Bus 
20764. ^ 

Having described the structure of MIC 20716 with reference to Rg. 207, and having prewously 
descrlt)ed the structure of MEM 10112 with reference to Rg, 201, MEM 10n2's control structure operation 
will next be described with reference to both figures 201 and 207. 

2. MEM 10112 Control Operation 

Refemng first to Rg. 207, JOPAR 20710, JIPAR 20712, and lOPAR 20714 are, as previously described, 
connected from PD Bus 10146 from JP 10114 and lOM Bus 10130 from lOS 1011& JPAR 20710, JIPAR 
20712. and lOPAR 20714 receive read and write request addresses from JP 10114 and lOS 10116 and store 
tirese addresses for subsequent service by MEM 101 12. As will be described further below, these address 
Inputs from JP 10114 and lOS 10116 include FlU information specifying whatdata manipulation operations 
?]?i?o^-£?^®"?®^ ^ ^^^^^ requested data is transferred to the requestor or written into MEM 
10112, information regarding the destination data read from MEM 10112 is to be provided to, information 
regarding the type of operation to be performed by MEM 10112, and information regarding operand length- 
Request address infonnation received and stored in JOPAR 20710, JIPAR 20712, and lOPAR 20714 is 
retained therein until MEM 10112 has initiated service of the corresponding requests. MEM 10112 will 
«xept further request address information into a given port register only after a previous request into that 
port has been serviced or aborted. Address information outputs from JOPAR 20710, JIPAR 20712 and 
lOPAR 20714 is transferred through PRMUX 20720 to Bus 207^ and from there to RM 20722, MC 201 16, 
and RU 20120 as service of indhddual requests is initiated. As will be described below, this address 
information will be transferred through PRMUX 20720 and Bus 20738 to LP 20724 for use in servicina a 
cache miss upon occurrence of a MC 201 16 miss. 

command and control signals pertinent to each requested memory operation from 
and. JOS 10116 through JPMC Bus 10147 and lOSC Bus 10131. PC 20716 indudes request 
arbitration ic^ic and port state logic. Request ariDitration logic determines the sequence in which 10, Jl, JO 
ports are serviced, and when each port is to be serviced. In determining the sequence of port service, 
request art)ftFation logic uses present port state information for each port from the port state logic' 
^J^^^^J^J^ JPMC Bus 10147 and lOMC Bus 10131 regarding each incoming request, and Informatiori 
from RM 20722 concerning the present state of operation of MEM 10112. Port state logic selects each 
particular port to be serviced and, by control signals through Bus 20738, enables transfer of each porf s 
request address infonnation from JOPAR 20710, JIPAR 20712, and lOPAR 20714 through PRMUX 20720 to 
Bus 20738 for use by the remainder of MEM 1 0112*5 control logic in servidng the selected port In addition 
to request Information received from JP 10114 and lOS 10116 through JPMC Bus 10147 and lOMC Bus 
^131, port state logic utilizes information from RM 20722 and, upon occurrence of a cache miss, from LM 
20730 (for clarity of presentation, this connection is not represented in Rg. 207). Port state logic also 
controls various port state flag signals, for example port availability signals, dgnals indicating valid 
requ^ts, and signals indicating that various ports are waiting service, 

RM 20722 controls execution of service for each request RM 20722 is a microcode controlled 

'micromachine" executing programs called for by requested MEM 10112 operations. Inputs of RM 20722 

indude request address information from lOPAR 20714, JIPAR 20212, and JOPAR 20210, Induding 

information regarding the type of MEM 101 12 operation to be performed in servidng a particular request, 

mterrupt signals from other MEM 1 01 12 control elements, and, for example, start signals from PC 20716*8 

^^."2?.^**^^**^" ^^^^ 2°^^ provides control signals to FlU 201 20, MC 201 16, and most other parts 
of MEM 10112's control structure. 

Refen-ing to Rg. »)1, MC 20116's cache is, for example, an 8 Kilo-byte, four set assodative cadie used 
to provide rapid access to a subset of data stored In MSB 20110. The subset of MSB 20110 data stored in 
MC 201 16*8 cache at any time is the data most recently used by JP 10114 or lOS 10116. MC 201 16*$ cache, 
described further below, indudes tag store comparison logic for determining encached addresses, a data' 
store containing corresponding encached data, and registers and logic necesary to up^Jate cache contents 
upon occurrence of a cache miss. Registere end logic for servidng cache misses indudes logic for 
determining the least recently used cache entry and registers for capture and storage of information 
regarding missed cache references, for example modify bits and replacement page numbers. Inputs to MC 
20116 are provided from RM 20722, LM 20730 (discussed forther below), FlU 20120, MSB 20110 (through 
BC 201 14), LP 20724 (described further below) and address information from PRMUX 20720. Outputs of MC 
20116 indude data and go to RU 20120 (through MOD Bus 10144), the data requesu>re (JP 10114 and lOS 
10116), and a MC 20116 Write Back RIe (described further below). 

As previously described, RU 20120 indudes logic nec^sary to make MEM 10112 appear bit 
addressable. In addition, RU 20120 includes logic for performing certain data manipulation operations as 
required by the requestore (JP 10114 or lOS 10116). Data is transfen-ed into FlU »)120 from MC 20116 
through that portion of MOD Bus 10144 internal to MEM 10112, is manipulated as required, and is then 
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transferred to the requestor through MOD Bus 10144 or MIO Bus 10129. In the case of w^^^^s requiring read- 
modlfy-write of encached data, the data is transferred back to MC 20116 through MOD Bus 10144 after 
manipulation. In general, data manipulation operations include locating requested data onto selected MOD 
Bus 10144 or MIO Bus 10139 lines and filling unused bus lines as specified by the requestor. Data inputs to 

5 nu 20120 may be provided from MC20116orJP 10114through MOD Bus 101 44 or from ^9? '^^'^ ^^1"'°^?^ 
lOM Bus 10130. Data outputs from FlU 20120 may be provided to MC 20116, JP 10114, or lOS 10116 
through these same buses. Control information is provlded-to FlU 20120 from RM 20722^rough Bus 20748 
and MCNTL-RU Bus 20164C. Address information may be provided to FlU 20120 from JQPAR 20710, JIPAR 
20712, or lOPAR 20714 through PRMUX 20720, Bus 20738, and MCNTL-FIU Bus 20164C. 

10 Returning to Fig. 207, MISSC 20726 Is used In handling MC 20116 misses. In the event of a request 
referring to data not In MC 20116's cache, MISSC 20726 stores block address of the of 
operation to be performed, this information being provided from an address register in MC 201 1 6 and from 
RM 20722. MISSC 20726 utilizes this information in generating a command to BC 20114, through mcntl- 
BC BUS-20164A, for a data read from MSB 20110 to obtain the referenced data. BC 20114 Peaces this 

t6 command in a queue, or register, and subsequently executes the commanded read operation. MISSC 
20726 also generates an entry into RQ 20728 ^described further below) indicating the type of operation to 
be perfomied when referenced data is subsequently read from MSB 201 10. 

RQ 20728 is, for example, a three-level deep queue storing information indicating operations 
associated with data being read from MSB 20110. Two kinds of operation may be indicated: blodc by-pa^ 

20 reads and cadie loads. H a cache load is specified, that Is a read and store to MC 201 1 6 s cache, is indicated, 
RM 20722 Is inteirupted and forced to place other MEM 10112 operations in idle until cache load is 
completed, A block by-pass read operation results in by-pass read control (described ^©low) assuming 
control of the data from MSB 201 1 0. Inputs to RQ 20728 are control signals from RM ^7^. MISSC 20726, 
and BQ 20114. RQ 20728 provides control outputs to LP 20724 (described below) LM »)730 {described 

2S below) RM 20722, and by-pass read control (described below). 

LP 20724 is a set of registers for storing Information necessary for servidng MC 20116 misses that 
result in order to load MC 201 la's tag store. LM 20730 uses this information when data stored in MSB 201 10 
and read from MSB 20110 to serynce a MC 20116 cache miss, becomes available through ^ 20114. Inputs 
to LP 20724 include the address of the missing reference, provided from JQPAR 20710, JIPAR 20712. or 

30 lOPAR 20714 through PRMUX 20720 and Bus 20738, commands from RM 20722, and a wmtrol siSJ^?^ 
RQ 20728. LP 20724 outputs Include addresses of missed references to MC 20116, through Bus 20756 and 
MNCTL-MC 20164B, and command «gnals to LM a)730 and BR/WC 20718. 

LM 20730. referred to above, controls loading of MC 20116's cache with data from MSB 20110 after 
occurrence of a cache miss, RQ 20728, referred to above, indicates, for each data read from MSB 20110, 

3S whether the data read is the result of a MC 201 16 cache miss. If the data is read from MSB 20110 as a r^tt 
of a cache miss, LM 20730 proceeds to issue a sequence of control signals for loading the data from MSB 
201 10 and Its assodated address Into MC 201 cache- This data is transferred into MC 201 16's cadie data 
store while the block address, from LP 20724 is transferred into the tag store (descnbed In the following 
discussion) of MC 20116's cache. If the transfer of data into MC 20116's cache replaces data previously 

40 resident in that cache, and that previous data is "dirty", that Is has been written into so as to be different 
from an original copy of the data stored on MSB 20110, the modified data resident in MC 20116's cache 
must be written back into MSB 201 10. This operation is perfonned through a Write Back File contained in 
MC 201 16 and described below. In the event of such an operation, LM 20730 initiates a write back operation 
by MC 201 16 and BC 201 14, also as described below. 

45 As will be descnbed further in a following description, ail MC 201 16 cache load operations are full 4 
wonJ blocks. A request resulting in a MC 20116 cache miss may result in a "hand-off', that is a read 
operation of a full 4 word block. Handoff operations also may be of single 32 bit words wherein a 32 bit 
worti aligned word is transferred from JP 10114 or a 16 bit operand aligned on the nght half-word is 
transfert«d from IDS 10116. In such a handoff operation, LM 20730 will send a valid request signal to the 

SO requesting port and a handoff operation will be performed. Otherwise, a wafting signal will be sent to the 
requesting port and the request will re-enter the priority queue of PC 20716 for subsequent execution. To 
accomplish these operations, LM 20730 receives input from RQ 20728, (not shown in Fig. 207 for darity of 
presentation) and LP 20724. LM 20730 provides ou^ts to port state logic of PC 20716, to MC 20116, MC 
20116's Write Back RIe and MC 20116's Write Back Address Register and to BC 20114. 

ss Refening to Fig. 201, as previously discussed lOS 20116 may request a full block wrii^ operation 
directly to MSB 20110. Such a by-pass write request may be honored if the block being transferred is not 
encached In MC 201 16's cache, in such a case, RM 20722 will Initiate the transfer setting up By-pass Write 
Control logic in BRWC 20718, and may then pass control of the operation over to BRAA/C 20718 s By-Pass 
Write Control logic for completion. By-pass Write Control may then accept the '^^'^a^^jns Portion of the 

€0 data block from lOS 10116, generating appropriate hand shaking signals through lOMC Bus 10131, and 
load the data block into BYF 20118 and MC 20116. MISSC 20726 will provide a bV'Pa^write comrnand to 
BC 201 14, tiirough MNCTL-PC Bus 20164A. BC 201 14 will then transfer the data block from BYF 201 1 8 and 
into MA'S 20112 and MSB 20110. ^ ^ ^ ^♦♦^or 

As previously described, BYF 201 18 receives data from lOM Bus 10130 and provides data output to BC 

65 201 14 through BWY Bus 20178 and SBD Bus 20146. BYF 20118 is capable of simultaneously accepting data 
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from lOM Bus 10130 while reading data out to BC 20114. Control of writing data into BYF 20118 is provided 
from BR/WC 20718's By^Pass Write Control logic. 

lOS 10116 may, as previous descn'lsed, request a full block read operation tyy-passing MC 20116*5 
cache. In such a case, BFWVC 20718's by*pass read control handles data transfer to iOS 10116 and 
^ generates required hand shaldng signals to lOS 101 16 through lOMC Bus 10131. The data path for by^pass 
read operations is through a data path internal to MC 20116, rather than through BYF 20118. This internal 
data path is ROO Bus 20158 to mO Bus 10129. 

As previously described, BC 20114 manages all data transfers to and from MA's 20112 in MSB 20110. 
BC 20114 receives requests for data transfers from RM 20722 in an intemal queue register. All data 
transfers to and from MSB 20110 are full block transfers with block aligned addresses. On data write 
operations, BC 201 14 receives data from BWF 201 18 or from MC 201 16's Write Back File and transfers the 
data into MA's 201 12. During read operations, BC 201 14 fetches the data block h^om MA's 201 12 and places 
the data block on RDO Bus 201^ while signalling to MIC 20122 that the data Is available. As described 
above, M IC 201 22 tracks and controls transfer of data and BYF 201 1 8, MC 201 1 6, and MC 201 1 B's Write Bade 
RIe, and directs data read from MSB 20110 to the appropriate destination, MC 20116's Data Store, JP 
10114, or IOS lOlia 

In addition to the above operations, BC 20114 controls refresh of MA's 20112 and performs error 
detection and correction operations. In this regard, BC 20114 performs two error detection and correction 
operations. In the first* BC 20114 detects single and double bit en-ors in data read from MSB 20110 and 

^ corrects single bit errors. In the second, BC 20114 reads data stored in MA's 20112 during refresh 
operations and performs single bit error detection. Whenever an error is detected, during either read 
operations or refresh operations, BC 20114 makes a record of that error in an error log contained in BC 
20114 (described further in a following description). Both JP 10114 and IOS 10116 may read BC 20114's 
error log, and information from BC 201 14's error log may be recorded in a CS 101 10 maintenance log and to 

^ assist in repair and trouble shooting of CS 10110. BC 201 14's error log may be addressed directly by RM 
20722 and data from BC 20114's error log is transferred to JP 10114 or IOS 10116 in the same manner as 
data stored in MSB 201 1 0. 

Referring finally to MA's 20112, each MA 20112 contains an array of dynamic semiconductor random 
access nrtemories. Each MA 20112 may contain 256 Kilo-t^ytes, 512 Kiio-bytes, 1 Mega*k>ytes, or 2 Mega- 

^ bytes of data storage. The storage capadty of each MA 201 1 2 is organized as segments of 256 IQto-bytes 
each« In addressing a particular MA 20112, BC 20114 selects that particular MA 20112 as will t>e described 
further below. BC 20114 concurrently selects a segment within that MA 201 12, and a t>lock of four wofds 
within that segment Each word may comprise 39 bits of information, 32 bits of data and 7 bits of error 
correcting code. The fiiil 39 bits of each MA 201 12 word are transferred between BC 201 14 and MA's 201 12 

^ during each read and write operation. Having briefly described the general structure and operation of MEM 
10112, certain types of operations which may be performed by MEM 10112 will be described next below. 

t MEM 10112 Operations 

MEM 10112 may perform two general types of operation. The first type are data transfer operations 

^ and the second type are memory maintenance operations. Data transfer operations may include read, 
write, and read and set Memory maintenance operations may include read error log, repair block, and 
flush cache. Except during a flush cache operation, the existence of MC 201 16 and its operation is invisible 
to the requestors, that is JP 10114 and IOS 10116. 

A MEM 10112 read operation transfers data from MS 10112 to a requestor, either JP 101 14. or IOS 

45 10116. A read data transfer is asynchronous in that the requestor cannot predict elapsed time between 
submission of a memory operation request and retum of requested data Operation of a requestor in MEM 
10112 is coordinated by a requested data available signal transmitted from MEM 10112 to the requestor. 

A MEM 10112 write operation transfers data from either JP 10114 or IOS 101 16 to MEM 10112. During 
such operations, JP 101 14 Is not required to wait for a signal from MEM 1 01 12 that data provided to MEM 

so 101 12 from JP 10114 has been accepted. JP 101 14 may transfer data to MEM 101 12's JO Port whenever a 
JO Port available signal from MEM 10112 is present; read data is accepted immediately without further 
action or waiting required of JP 10114. Word write operations from IOS 10116 are performed in a similar 
manner. On block write operations, however, IOS 10116 is required to wait for a data taken signal from 
MEM 10112 before sending the 2nd, 3rd and 4th words of a block. 

55 MEM 10112 has a capability to perform 'Mock bit" operatioris. In such operations, a bit granular read of 
the data is performed and the entire operarni is transmitted to the requestor. At the same time, the mo^ 
^gntficant bit of the operand, that is the Lock Bit, Is set to one In the copy of data stored in MEM 10112. In 
the operand sent to the requestor, the lock bit remains at its previous value, the value before the current 
read and set operation. Te^ and set operations are performed by performing read and set operations 

60 wherein the data item length is specified to be one bit 

As previously described. MEM 10112 performs certain maintenance operations, including error 
detection. MEM 10112's Error Log in BC 20114 is a 32 bit register containing an address field ar>d an error 
code field. On a first error to occur, the error type and in some cases, such as ERCC errors on read data 
stored in MSB 20110, the address of the data containing the error are stored in BC 20114's Error Log 

65 Register. An Interrupt signal indicating detection of an error is raised at the same that information 
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regarding the error is stored in the Error Log. If multiple errors occur before Error Log Is read and reset, the 
information regarding the first error will be retained and will remain valid. The Error Log code field will, 
however, indicate that more than one error has occurred. 

JP 10114 may request a read Error Log operation referred to as a "Read Log and Reset" operation. In 

s this operation, MEM 10112 reads the entire contents of Error Log to JP 101 14, resets En-or Log Register, and 
resets the interrupt signal indicating presence of an error. lOS 10116, as discussed further below, is limited 
to reading 16 bits at a time from MEM 10112. It therefore requires two read operations to read Error Log. 
Rrct read operation to ICS 10116 reads an upper 16 bits of Error Log data and does not reset Error Log. The 
second read operation is performed in the same manner as a JP 10114 Read Log and Reset operation, 

'fl except that only the low order 16 bits of Error Log are read to lOS 101 16. 

MEM 10112 performs repair block operations to correct parity or ERCC ent>rs In data stored In MC 
201 irs Cache or in data stored In MA's 201 12, In a repair block procedure, parity bits for data stored in MC 
201 16's Cache, or ERCC check bits of data stored in MA's 201 12, are modified to agree with the data bits of 
data stored therein. In this regard, repaired unconectible errors, such as two bit errors of data in MA's 

w 201 12, will have good ERCC and parity values. Until a repair block operation Is performed, any read request 
directed to bad data, that is data having parity or ERCC check bits indicating invalid data, will be flagged as 
invalid. Repair block operations therefore allow such data to be read as valid, for example to be used in a 
data correction operation. Errors are ignored and not logged in BC 20114's Error Log m repair block 
operations. A write operation Into an area containing bad data may be accomplished if MEM 10112's 
internal operation does not require a read-modified-write procedure. Only byte aligned writes of integral 
byte length data residing in MC 20116 and word aligned writes of integral word lengths of data in MSP 
20110 do not require read-modified-write operation. By utilizing such write operations, it is therefore 
possible to overwrite bad data by use of normal write operations before or instead of repair block 
operations. 

26 M EM 1 011 2 performs a cache flush operation in event of a power failure, that is when MEM 1 01 1 2 goes 
into battery back-up operation. In such an event, only MA's 20112 and BC 201 14 remain powvered. Before JP 
10114 and lOS 101 16 lose power, JP 10114 and lOS 10116 must transfer to MEM 10112 any data, including 
operating state, to be saved. This is accomplished by using a series of normal write operations. After 
conclusion of these write operations, both JP 10114 and lOS 10116transmit a flush cache request to MEM 

30 101 12. Upon receiving two flush cache requests, MEM 101 12 flushes MC 201 16's Cache so that all dirty data 
encadied in MC 201 1 6's Cache is transferred into MA's 201 12 before power is lost If only JP 101 14 or lOS 
101 16 is operating, DP 101 18 will detect this fact and will have transmitted an enabling signal {FLUSHOKJ to 
MEM 10112 during system initialization. FLUSHOK enables MEM 10112 to perform cache flu^ upon 
receiving a single flush cache request After a cache flush operation, no further MEM 10112 operations are 

35 possible until Dp 10118 resets a power failure lock-out signal to enable MEM 10112 to resume normal 

operation. ........ w 

Having described MEM 101 irs overall structure and operation and certain operations whia» may be 
performed by MEM 10112, MEM 101 1 2's interfaces to JP 101 14 and lOS 101 16 will be described next below. 

40 a MEM 10112 Interfaces to JP 10114 and IDS 10116 (Rgs. 209, 210, 211, 204) 

As previously described, MJP Port 10140 and MIO Port 10128 logically function as three independent 
ports. These ports are an lO Portto lOS 101 16, a JP Operand Port to JP 1 01 14 and a JP Instruction Port to JP 
101 14. Referring to figs. 209, 210, and 21 1 , diagramic representations of 10 Port 20910, JP Operand (JPO) 
Port 21010, and JP Instruction (JPI) port 21110 are shown respectively. 

45 10 Port 20910 handles all lOS 10116 requests to MEM 10112, including transfer of both instructions and 
operands. JPO Port 21010 is used for read and write operations of operands, for example numeric values, 
to and from JP 101 14. JPI Port 21110 is used to read SINs. that is SOPs and operand NAMEs. from MEM 
101 12 to JP 101 14. Memory service requests to a particular port are serviced in the order that the requests 
are provided to the Port. Serial order is not maintained between requests to different ports, but ports may 

50 be serviced in the order of their priority. In one embodiment of the present invention, 10 Port 20910 is 
accorded highest priority, followed by JPO port 21010, and lastiy by JPI Port 21 1 10, with requests currently 
contained in a port having priority over incoming requests. As described above and will be described In 
more detail in following descriptions, MEM 10112 operations are pipelined. This pipelining allows 
interieaving of requests from 10 Port 20910, JPO Port 21010, and JPI port 21110, as well as overtapping 

55 service of requests at a particular port By overiapping operations It is meant that one operation servicing a 
particular port begins before a previous operation servicing that port has been completed. 

1. 10 Port 20910 Operating Characteristics (Rgs. 209, 204) 

Referring first to Rg. 209, a diagramic representation of 10 port 20910 Is shown. Signals are transmitted 

eo between 10 Port 20910 and lOS 10116 through MIO Bus 10129, lOM Bus 10130, and lOMC Bus 10131 . MIO 
Bus 10129 is a unidirectional bus having Inputs from MC 20116 and RU 20120 and dedicated to transfers of 
data and Instructions from MEM 10112to lOS 10118. lOM Bus 10130 is likewise a unidirectional bus and is 
dedicated to the transfer, from lOS 101 18 to MEM 101 12, of read addresses, write addresses, and data to be 
written into MEM 10112. lOM Bus 10130 provides inputs to BYF 20118, RU 20120, and MIC 20122 lOMC 

65 Bus 10131 is a set of dedicated signal linesforthe exchange ofcontrol signals between lOS 101 18 and MEM 
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10112. 

Referring first to MIO Bus 10129, MIO Bus 10129 is a 36 bit bus receiving read data inputs from MC 
20116's Cache and from FiU 20120. A single read operation from MEM 10112to lOS 10116 transfers one 32 
bit word (or 4 bytes) of data (MiO(0— 31 )) and four bits of odd parity (MIOP(0— 3)), or one parity bit per byte, 
s Referring next to lOM Bus 10130, a single transfer from lOS 10116 to MEM 10112 includes 36 bits of 

information which may comprise either a memory request comprising a physical address, a tme iength, 
and command bits. These memory requests and data are multiplexed onto lOM 10130 by lOS 10116. 

Data transfers from lOS 101 16 to MEM 101 12 each comprise a single 32 bit data word {10M{0— 31 )) and 
four bits of odd parity (IOMP(0— 3)) or one parity bit per byte. Such data transfers are received by either 6 YF 
fO 20118 or RU 20120. 

Each lOS 10116 memory request to MEM 10112, as described above, an address field, a length field, 
and an operation code field. Address and length fields occupy the 32 lOM Bu$ 10130 lines used for transfer 
of data to MEM 10112 in lOS 10116 write operations. Length field indudes four bits of Information 
occupying bits (IOM(03]) of lOM Bus 10130 and address field contains 27 bits of information occupying bits 
(I0M(4— 31)) of lOM Bus 10130. Together, address and length field specify a physicai starting address and 
true length of the particular data item to be written Into or read from MEM 10112. Operation code field 
specifies the type of operation to be performed by MEM 10112. Certain basic operation codes comprise 3 
bits of information occupying bits (lOMP (32->36)) of IGM Bus 10130; as described above. These same lines 
are used for transfer of parity bits during data transfers. Certain operations which may be requested of 
20 MEM 10112 by ICS 101 16 are, together with their corresponding command code fields, are; 



000 


» read. 


001 


= read and set 


010 


= write. 


oil 


=5 error. 


100 


= read error log (first half). 


101 


= read error log (second half) and reset. 


110 


« repair bloclg and 


111 


= fiush cache. 



30 

Two further command bits may specify further operations to be perfonmed by MEM 10112, A first 
command bit, indicates to MEM 10112 during write operations whether it is desirable to encache the data 
being written into MEM 101 12 in MC 201 16's Cache. ICS 101 16 may set this bit to zero if reuse of the data is 
unlikely, thereby indicating to MEM 10112 that MEM 10112 should avoid encaching the data. lOS 10116 

35 may set this bit to one if the data is likely to be reused, thereby indicating to MEM 101 12 that It is preferable 
to encache the data. A second comniand bit is referred to a CYCLE. CYCLE command bit Indicates to MEM 
10112 whether a particular data transfer is a single cyde operation, that is a bit granular word, or a four 
cycle operation, that is a block aligned block or a byte aligned partial block. 

lOMC 10131 includes a set of dedicated Tines for exdiange of control signals between lOS 10116 and 

40 MEM 10112 to coordinate operation of lOS 10116 and MEM 10112. A first such signal is Load 10 Request 
(UOR)from IDS 10116 to MEM 10112. When lOS 10116 vwshes to load a memory request into MEM 10112, 
lOS 10116 asserts UOR to MEM 10112. lOS 10116 must assert UOR during the same system cyde during 
which ^e memory requ^ that is address, length, and command code fields, are valid. 

If UOR and 10 Port Available (lOPA) signals, described below, are asserted during the same dock cyde, 

45 MEM 101 12's port is loaded from lOS 101 16 and lOPA is dropped, indicating the request has been accepted. 
If a load of a request is attempted and lOPA is not asserted, MEM 10112 remains unaware of the request 
UOR remains active, and the request must then be repeated when lOPA is asserted. 

lOPA is a signal from MEM 10112 to lOS 10116 vi/hich is asserted by MEM 10112 when MEM 10112 Is' 
available to accept a new request from lOS 101 16. lOPA may be asserted while a previous request from lOS 

50 10116 Is completing operation if the address, length, and operation code fields of the previous request are 
no longer required by MEM 10112, for example in servicing bypass operations. 

10 Data Taken (TIOMO) Is a signal from MEM 10112 to 10$ 10116 indicating that MEM 10112 has 
accepted data from lOS 10116. lOS 10116 places a first data word on lOM Bus 10130 on the next system 
dock cycle after a write request is loaded; that is, UOR has been asserted, a memory request presented, 

ss and lOPA dropped. MEM 10112 then takes that data word on the clock edge beginning the next system 
dock cycle. At this point MEM 10112 asserts TIOMD to Indicate the data has been accepted. On a single 
word operations TIOMD is not used by lOS 101 16 as a first data word is always accepted by MEM 101 12 if 
10 Port 20910 was available. On block operations, a first data word is always taken but a delay may occur 
between acceptance of first and second words. lOS 1 0116 is required to hold the second word valid on lOM 

60 Bus 10130 until MEM 10112 responds with TIOMD to indicate that the block operation may pnoceed. 

Data Available for 10 (DAVIO) is a signal asserted by MEM 10112 to lOS 10116 indicating that data 
requested by lOS 10116 is available; DAVIO Is asserted by MEM 10112 during the system clock cyde In 
which MEM 101 12 places the requested data on MIO Bus 10129. In any single vrard type transfer, DAVIO is 
active for a single system clock transfer, in block type transfers, DAVIO is rKsnnally active for four 

& consecutive system clock cycles. Upon event of a single cyde "bubble" resulting from detection and 
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correction of an ERCC error by BC 20114, DAVIO will remain high for four non-consecutive system dock 
cycles and with a single cyde bubble, a non-assertion« In DAVIO corresponding to the detection and 
correction of the error. 

10 Memory interrupt (IMINT) is a signal asserted by MEM 101 12 to lOS 10116 when BC 20114 places a 

5 reconj of a detected error in BC 20114's Error Log, as described above. 

Previous MIO Transfer invalid <PMIOI) signal is similarly a signal asserted by MEM 10112 to lOS 10116 
regarding errors in data read from MEM 101 12 to IDS 101 16. If an uncorrectible error appears in such data, 
that is an error In two or more data bits, the Incorrect data Is read to lOS 10116 and PMIOI signal asserted fcry 
MEM 10112. Correctible, or single bit errors In data do not result in assertion of PMIOI. MEM 10112 will 

to assert PMIOI to lOS 10116 of the next system clock cycle following MEM 10112's assertion of DAVIO. 

Having descrii^ed MEM 10112's interface to lOS 10116, and certain operations which lOS 10116 may 
request of MEM 10112. certain MEM 10112 operations within the capability of the interface will be 
described next. First, operand transfers, for example of numeric data, between MEM 10112 and lOS 10116 
may be bit granular with any length from one to sl3cteen bits. Operand transfers may cross boundanes 
within a page but may not cross phy^cal page boundaries. As previously described, MIO Bus 10129 and 
lOM Bus 10130 are capable of transferring 32 bits of data at a time. The least significant 16 bits of these 
buses, that is bits 18 to 31, will contain right justified data during operand transfers. The contents of the 
most significant 16 bits of these buses is generaliy not defined as MEM 10112 generally does not perform 
fHf operations on read operations to 10 Port 20910, nor does iOS 10116 fill unused bits during write 

2& operations* During a read or write operation, only those data bits indicated by length field in the 
corresponding memory request are of significance. In all cases, however, parity must be valid on all 32 bits 
of MIO Bus 10129 and iOM Bus 10130. 

Referring to Rg. 204, IOS 10116 includes Data Channets 20410 and 20412 each of which will be 
descrit>ed further in a following detailed description of IOS 10116. Data Channels 20410 and 20412 each 

2S possess particular characteristics defining certain 10 Port 20910 operations. Data Channel 20410 operates 
to read and write blodc aligned ^11 and partial blocks. Full blocks have block aligned addresses and lengths 
. of 16 bytes. Partial blocks have byte aligned addresses and ieng^s of 1 to 15 bytes; a partial block transfer 
must be within a blocks that is not cross block boundaries. A full 4 word block will be transferred between 
IOS 10116 and MEM 10112 in either case, but only those blocks indicated by length of field In a 

30 oorre^onding MEM 10112 request are of actu^ significance in a write operation. Non-addressed tiytes In 
such operations may contain any Information so long as parity is valid for the entire data transfer. Data 
Channel 20412 preferably reads or writes 16 bits at a time on double byte boundaries. Such reads and 
writes are right justified on MIO Bus 10129 and IOM Bus 10130. The nru>st significant 16 bits of these iMises 
may contain any Information during such operations so long as parity is valid for the entire 32 bits. Data 

^ Channel 20412 operations are similar to IOS 10116 operand read and write operations wi^ double byte 
aligned addresses and lengths of 16 bits. Rnally, Instructions, for example controlling IOS 1011 6 operation, 
are read from MEM 101 12 to IOS 101 16 a block at a time. Such operations are identical u> a Hill block data 
read. 

Having described the operating characteristics of 10 Port 20910, the operating cliaracteristics of JPO 
40 Port 21010 will be described next 

2, JPO Port 21010 Operating Characteristics (Fig. 210) 

Referring to Rg, 210, a cfiagramic representation of JPO Port 21010 is shown. As previously described, 
JPO Port 21010 is utilized for transfer of operands, for example numeric data, betwe^ MEM 101 12 and JP 

4$ 1011 4. JPO Port 21010 includes a request input (address, length, and operation information) to MIC 20122 
from 36 bit PD Bus 10146, a write data input to RU 20120 from 32 bit JPD Bus 10142, a 32 bit read data 
output from MC 20116 and FlU 20120 to 32 bit MOD Bus 10144, and bi-directional control inputs and 
outputs between MIC 20122 and JPMC Bus 10147. 

Referring first to JPO Port 21010's read data output to MOD Bus 10144, MOD Bus 10144 is used by JPO 

so Port 21010 to transfer data, for example operands, to JP 101 14. MOD Bus 10144 is also utilized internal to 
MEM 10112 as a bidirectional bus to transfer data between MC 20116 and RU 20120. In this manner, data 
may be transferred from MC 201 1 6 to FlU 201 20 where certain data format operations are performed on the 
data before the data is transferred to JP 101 14 through MOD Bus 10144. Data may also be used to transfer 
data from RU 20120 to MC 20116 after a data format operation is performed in a write operation. Data may 

ss also be transferred directiy from MC 201 16 to JP 101 14 through MOD Bus 10144. Internal to MEM 101 12, 
MOD Bus 10144 is a 36 bit bus for concurrent transfer of 32 bits of data, MOD Bus 10144 bits {MOD(0— 31)), 
and 4 bits of odd parityr 1 bft per byte, MOD Bus 10144 bits (MODP(0— 3)). External to MEM 101 12, MOD 
Bus 10144 is a 32 bit bus, comprising bits (MOD{0— 31)); parity bits are not read to JP 10114, 

Data is wriuen into MEM 10112 through JPD Bus 10142 to RU 20120. As just described, data format 

GO operations may then be performed on this data before it is transferred from FlU 20120 to MC 201 16 through 
MOD Bus 10144. In such operations, JPD Bus 10142 operates as a 32 bit bus carrying 32 bits of data, bits 
(JPD (0--^1)), with no parity bits. JO Port 21010 generates parity for JPD Bus 10142 data to be written Into 
MEM 10112 as this data is transferred into MEM 10112. 

Memory requests are also transmitted to MEM 10112 from JP 10114 through JPD Bus 10142, which 

es operates in this regard as a 40 bit bus. Each such request includes an address field, a length field, an FlU 
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field specifying data formating operations to be performed, operation code fteid. and a donation code 
field specifying destination of data read from MEM 10112. Address field includes a 13 bit physical page 
number field, (JPPN(a-12)), and a 14 bit physical page offset field, UPP0(a-13)). Length field includes 6 
bits of length information, (JLNG(0— 5)), and expresses true length of the data item to be written to or read 
s from f^EM 10112. 

As JPD Bus 10142 and MOD Bus 10144 are each capable of transferring 32 bits of data in a single MEM 
10112 read or write cycle, 6 bits of length information are required to express true length. As will be 
described in a following description, JP 10114 may provide physical page offset and length information 
directly to MEM 10112, performs logical page number to physical page number transiations, and may 

'(^ perform a Protection Mechanism 102^ checlc on the resulting physical page number. As such, MEM 10112 
expects to receive (JPPNIO— 12» later than (JPPOtO— 13)) and (JLNG(<>--5|). WPPO(0— 13)) and 
{JLNG(0— 5)} should, however, be valid during the system clock cycle in which a JP 10114 memory request 
is loaded into MEM 10112. 

Operation code field provided to MEM 101 12 from JP 101 14 is a 3 bit code, (JMCMD(0— 2)) spedfying 

IS an opmtton to be formed by MEM 101 12. Certain operations which JP 101 14 may request of MEM 101 12, 
and their corresponding operation codes, are: 

read; 

read and set; 
write; 
error; 
error; 

read error log and reset; 
repair block; and, 
flush cache. 

Two bit RU field, {JFIUCO— 1)) specifies data manipulation operations to be performed in executing 
read and write operations. Among tiie data manipulation operations which may be requested by JP 101 14, 
and their FlU fieldsr are: 

30 

00 - right justrlied, zero fill; 

01 right Justified, dgn extend; 

10 = left justify, zero fill; and, 

11 left justify, blank fill. 

3S 

For write operations, JPO Port 21010 may respond only to the most agnificant bit of RU field, that is 
the FIU field bit specifying alignment 

Rnally, destination field is a two bit field specifying a JP 101 14 destination for data read from MEM 
10112. This field is ignored for write operations to MEM 10112. A first bit of destination fieki, JPMDST, 
40 identifies the destination to be FU 10120, and tiie second field, EBMDST, spedfies EU 10120 as the 
destination. 

JPMC Bus 10147 includes dedicated lines for exchange of control signals between JPO Port 21010 and 
JP 101 14. Among these control signals is Load JO Request (UOR), which is asserted by JP 101 14 when JP 
10114 wishes to load a r^uest into MEM 10112, UOR is asserted concurrentiy with presentation of the 

45 memory request to MEM 1011 2 through PD Bus 10146. JO Port Available (JOPA) is asserted by MEM 101 12 
when JPO Port 21010 is available to accept a new memory request from JP 10114. If UOR and JOPA are 
asserted concurrently, MEM 10112 accepts the memory request from JP 10114 and MEM 10112 drops 
JOPA to indicate that memory request has been accepted. As previously discussed, MEM 10112 may assert 
JOPA while a previous request is being executed and the PO Bus 10146 information, that is the memory 

50 request previously provided concerning the pre\^ous request is no longer required. 

If JP 10114 submits a memory request and JOPA is not asserted by MEM 10112, MEM 10112 does not 
acc^tthe request and JP 10114 must resubmit that request when JOPA is asserted. Because, as described 
above, JPf^ field of a memory request from JP 10114 may arrive late compared to the other fields of the 
request, MEM 10112 wilt delay loading of JPPN field for a particular request until the next system clock 

55 cycle after the request was initially submitted. MEM 101 12 may also obtain this JPPN field at the same time 
it is being loaded into the port register by by-passang the port register. 

JP 101 14 may abort a memory request upon asserting Abort JP Request (ABJR). ABJR will be accepted 
by MEM 10112 during system clock cyde after accepting memory request from JP 10114 and ABJR will 
result in cancellation of the requested operation. A single ABJR line is provided for both JPO Port 21010 

60 and JPI Port 21 1 1 0 because, as described in a following description, MEM 1 01 12 may accept only a single 
request from JP 101 14, to either JPO Port 21010 or to JPI port 21 1 10, during a single system clock cycle. 

Upon completion of an operand read operation requested through JPO Port 21010 MEM 10112 may 
assert either of two data available signals to JP 10114. These signals are data available for FA(DAVFA) and 
data available for EB{DAVEB). As previously described, a part of each read request from JP 101 14 indudes 

& a destination field spedfying the Intended destination of the requested data. As will be described further . 
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below, MEM 10112 tracks such destination information for read requests and returns destination 
information with a corresponding information in the form of DAVFA and DAVEB. DAVFA indicates a 
destination in FU 10120 while DAVEB indicates a destination in EU 10122. MEM 10112 may also assert 
signal zero filled (ZFILL) specifying whether read data for JPO Port 21010 is zero filled. ZRa is valid only 
* when DAVEB is asserted. 

For JPO Port 21 01 0 write request, the associated write data word should be valid on same system clock 
cycle as the request, or one system clock cycle later. JP 1 01 1 4 asserts Load JP Write Data (U WD) during the 
system clock cycle when JP 10114 places valid write data on JPD Bus 10142, 

As previously discussed^ when MEM 101 12 detects an error in servicing a JP 1 01 14 request MEM 10112 
places a record of this error in MC 201 lO^s Error l-og. When an entry is placed in Error Log for either JPO 
Port 2101 0 or 10 Port 20910, MEM 101 12 asserts an interrupt flag signal indicating a valid Error Log entry is 
present DP 10118 detects this flag signal and may direct the flag signal to either JP 10114 or lOS 10116, or 
both. lOS 101 1 6 or JP 101 14, as selected by DP 101 18, may then read and reset Error Log and reset the flag. 
The Interrupt flag signal is not necessarily directed to the requestor, JP 101 14 or lOS 101 16, whose request 
resulted in the error. 

If an uncorrecdble MEM 10112 error, that is an error in two or more bits of a single data word. Is 
detected in a read operation the Incorrect data is read to JP 10114 and an invalid data signal asserted. A 
signal. Previous MOD Transfer Invalid (PMODI), is asserted by MEM 10112 on the next system clock cycle 
following either DAVFA or DAVEB. PMODI is not asserted for single bit errors, instead the data is corrected 
^ and the corrected data read to JP 1 01 14. 

Having described JPO Port 2t010's stnjcture, and characteristics. JPI Port 211 10 will be described next 
below. 

3. JPI Port 21110 Operating Characteristics (Rg. 211] 

Refernngto Rg. 211. a diagramic represema^ of JPI Port 211 10 Is shown. JPI port 211 10 includes an 
address input from PD Bus 10146 to FlU 20120, a data output to MOO Bus 10144 from MC 201 16, and bi- 
directional control inputs and outputs from MIC 20122 to JPMC Bus 10147. As previously described, a 
primary function of JPI Port 21110 is the transfer of SOPs and operand NAMEs from MEM 10112 to JP 
10114 upon request from JP 10114. JPI Port thereby performs only read operations wherein each read 

30 operation is a transfer of a single 32 bit word having a word aligned address. 

Referring to JPI Port 21 1 10 Input from PD Bus 10146, read requests to MEM 10112 by JP 10114for SOPs 
and operand NAMEs each comprise a 21 bit word address. As described above, each JPI Port 21 1 10 read 
operation is of a single 32 bit word. As such, the five least ^gnificant bits of address are Ignored by IMEM 
10112. For the same reason, a JPI Port 21110 request to MEM 10112 does not include a length field, an 

^ operation code field,' an RU field, or a destination code field. Length, operation code, and HU code fields 
are not required since JPI Port 21 1 1 0 performs only a single type of operation and destination code field is 
not required because destination is inherent In a JPI Port 21110 request 

The 32 bit words read from MEM 10112 In response to JPI Port 21110 requests are transferred to JP 
10114 through MC 201 16's 32 bit output to MOD Bus 10144. As in the case of JPO 21010 read outputs to JP 

40 10114, JPI Port 21110 does not provicte parity information to JP 10114. 

Control signals exchange between JP 10114 and JPI Port 21110through JPMC Bus 10147 Include Load 
Jl Request (LJIR) and JI Port Available (JlPA), which operate in the same manner as discussed with 
reference to JPO Port 21010. As previously described, JPO Port 21010 and JPI Port 21110 share a single 
Abort JP Request {ABJH) command. Stmilariy, JPO Port 21010 and JPI Port 21110 share previous MOD 

45 Transfer Invalid IPMODI) from MEM 101 12. As described above, a JPI port 21 1 10 request does not include a 
destination field as destination is implied. MEM 10112 does, however, provide a Data Available Signal 
(DAVFI) to JP 101 14 when a word read from MEM 10112 in response to a JPI Port 21110 request Is present 
on MOD Bus 10144 and valid. 

Having described the overall structure and operation of MEM 101 1 2, and the structure and operation of 

so MEM 101 12's interface to JP 101 14 and lOS 101 16, the structure and operation of RU 20120 MEM 10112 will 
next be described in further detail. 

h. RU 20120 (Figs. 201, 230, 231) 

As previously described, RU 20120 performs certain data manipulation operations, including those 

56 operations necessary to make MEM 10112 bit addressable. Data manipulation operations may be 
performed on data being written into MEM 10112, for example, JP 10114 through JPD Bus 10142 or from 
lOS 10116 through lOM Bus 10130. Data manipulations operations may also be performed on data being 
read from MEM 101 12 to JPD 10114 or lOS 10116. In case of data read to JP 10114, MOD Bus 10144 Is used 
both as a MEM 101 12 intemal bus. In transferring data from MC 20116 to RU 201 20 for manipulation, and to 

GO transfer manipulated data from MEM 10112 to JP 10114. In case of data read to 103 10116, MOD Bus 10144 
is again used as MEM 10112 intemal bus to read data from MC 20116 to FlU 20120 for subsequent 
manipulation. The manipulated data is then read from RU 20120 to lOS 10116 through MIO Bus 1012S, 

Certain data manipulation operations which may be performed by RU 20120 have been previously 
described. In general, a data manipulation operation consists of four distinct operations, and FlU 20120 

65 may manipulate data in any possible manner which may be achieved through performing any combination 
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of these operations. These four possible operations are sele<^on of data to be manipulated, rotation or 
shifting of that data, masking of that data* and transfer of that manipulated data to a selected destination. 
Each FlU 20120 data input will comprise a thirty-two bit data word and, as described above, may be 
selected from input provided from JPD Bus 10142, MOD Bus 10144, and lOM Bus 10130. In certain cases, an 
^ RU 201 20 data Input may comprise two thirty-two bit words, for example, when a cross word operation is 
performed generating an output comprised of bits from each of two different thirty-two bh words. Rotation 
or shifting of a selected thirty-two bit date word enables bits within a selected word to be repositioned with 
respect to word boundaries. When used in conjunction with the masking operation, described 
momentarily, rotation and shifting may be reiterably performed to transfer any selected bits In a word to 
any selected locations in that vwrd. As will be described further below, a masking operation allows any 
selected bits of a word to be affectively erased, thus leaving only certain other selected bits, or certain 
selected bits to be forced to predetermined values. A masking operation may be performed, for example, to 
zero fill or sign extend portions of a thirty-two bit word. In conjunction with a rotation or shifting operation, 
a masking operation may, for example, select a single bit of a thirty-two bit input word, position that bit in 
any selected bit location, and force all other bits of that word to zero. Each output of FlU 20120 Is a thirty- 
two bit data word and, as described above, may be transferred on to MOD Bus 10144 or onto MIO Bus« 
10129. As will be described below, selection of a particular sequence of the above four operations to be 
performed on a particular data word is determined by control inputs provided from MIC 20122. These 
control inputs from MIC 20122 are decoded and executed by microinstruction control logic Included within 
^ RU 20120. 

Referring to Rg. 230, a partial block diagram of RU 20120 Is shbwn. As indicated therein, RU 20120 
includes Data Manipulation Circuitry (DMC) 23010 and RU Control Circuitry (RUC) 2^12. Data 
Manipulation Circuitry 23010 in turn includes FlUlO circuitry (FlUlO) 23014, Data Shifter (DS) 23016, Mask 
•Logic (MSK) 23018, and Assembly Register (AR) logic 23020. Data manipulation circuitry 23010 will be 

^ described first followed by RUC 23012. In describing data manipulation drcuitry 23010, RUlO 2^^ 
described first, followed by DS 23016, MSK 23018, and AR 23020, in tiiat order. 

Referring to RUlO 23014, RUlO 23014 comprises RU 201 20*$ data input and output circuitry. Job 
Processor Write Data Register (JWDR) 23022, ID System Write Data Register (IWDR) 23024, and Write Input 
Data Register (RIDR) 23026 are connected from, respectively, JPD Bus 10142, lOM Bus 10130, and MOD Bus 

30 10144 for receiving data word inputs from, respectively, JP 101 14, lOS 101 16, and MC 201 16. JWDR 23022, 
IWDR 23024 and RIDR 23026 are each thirty-sfoc bit registers comprised, for example, of SlSi74S374 
registers. Data words transferred into IWDR 23024 and RIDR 23026 are each, as previously <tescribed, 
comprised of a thirty-two data word plus four bits of parity. Data Inputs from JP 10114 are, however, as 
previously described, thirty-two bit data words without parity. Job Processor Parity Generator (JPPG) 

^ assodated with JWDR 23022 is connected from JPD Bus 10142 and generates four bits of parity for 

. each data mput to JWDR 23022. JWDR 23022's thirty^'oc bit input thereby comprises thirty-two bits of data, 
directly from JPD Bus 10142, plus a corresponding four bits of parity from JPPG 23028. 

Data words, thirty-two bits of data plus four bits of parity, are transferred into JWDR 23022, IWDR 
23024, or RIDR 23026 when, respectively, input enable signals Load JWD <LJWD), Load IWD (UWD) or Load 

40 RID (LRID) are asserted. LJWD is provided from FU 10120 while UWD and LRID are provided from MIC 
20122. 

Data words resident in JWDR 23022, IWDR 23024, or RIDR 23026 may be selected and transferred onto 
RU 20120's Internal Data (IB) Bus 23030 by output enable signals JWD Enable Output (JWDEO), IWD 
Enable Output (IWDEO), an RID Enable Output (RIDEO). JWreO, IWDEO, and RDIEO are provided from 

45 RUC 23012 described below. 

As will be described further t^elow, manipulated data words from DS 23016 or AR 23020 will be 
transferred onto, respectively. Data Shifter Output (DSO) Bus 23032 or Assembly Register Output (ASYRO) 
Bus 23034 for sut>sequent transfer onto MOD Bus 10144 or MIO Bus 10129. Each manipulated data vrard 
appearing on DSO Bus 23032 or ASYRO Bus 23034 will be comprised of 32 bits of data plus 4 bits of parity. 

50 Manipulated data words present on DSO Bus 23032 may be transferred onto MOD Bus 10144 or MIO Bus 
10123 through, respectively, DSO Bus To MOD Bus Driver Gate (DSMOD) 23036 or BSO Bus To MIO Bus 
Driver Gate (DSMIO) 230^. Manipulated data words present on ASYRO Bus 23034 may be transferred onto 
MOD Bus 10144 or MIO Bus 10129 through, respectively, ASYRO Bus To MOD Bus Driver Gate (ASYMOD) 
23040 or ASYRO Bus To MIO Bus Driver Gate (ASYMIO) 23042. DSMOD 23036, DSMIO 23038, ASYMOD 

S6 23040, and ASYMIO 23042 are each comprised of, for example, SN74S244 drivers. A manipulated data 
word on 080 Bus 23032 be transfen-ed through DSMOD 23036 to MOD Bus 1 0144 when driver gate enable 
signal Driver Shift to MOD (DRVSHFMOD) to DSMOD 23036 Is asserted. Similariy, a manipulated data 
word on DSO Bus 23032 will be transferred through DSMIO 23038 to MIO Bus 101^ when driver gate 
enable signal Drive Shift Through MIO Bus (DRVSHFMIO) to DSMIO 23038 is asserted. Manipulated data 

eo words present on ASYRO Bus 23034 may be transferred onto MOD Bus 10144 or MIO Bus 10129 when, 
respectively, driver gate enable signal Drive Assembly To Mod Bus (DRVASYMOD) to ASYMOD 23040 or 
Drive Assembly To MIO Bus (DRVASYMIO) to ASYMIO 23042 are asserted. DRVSHFMCM), DRVSHFMIO, 
DRVASYMOD, and DRVASYMIO are provided, as described below, from FlUC 23012. 

Registers lARM 23044 and BARMR 23046, which will be described further in a follovnng description of 

6? DP 10118, are used by DP 10118 to, respectively, write data words onto IB 23030 and to Read data words 
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from MOD Bus 10144. for example manipulated data words from FlU 20120. Data word written into lARMR 
23044 from DP 10118, that is 32 bits of data and 4 bits of parity, will be transferred onto IB Bus 23030 when 
register enable output signal lARIVI enable output (lARMEO) from RUC 23012 is asserted. Simflarly, a data 
word present on MOD Bus 101 44, comprising 32 bits of data plus 4 bits of parity, wiil be written into BARMR 

5 23046 when load enable signal Load BARMR {LDBARMR> to BARMR 23046 is asserted by MiC 201 22. A data 
word written into BARMR 23046 from MOD Bus 10144 may then subsequently be read to DP 10118. lARMR 
23044 and BARMR 23046 are similar to JWDR 23022, IWDR 23024, and IRDR 23026 and may be comprised, 
for example, of SN74S299 registers. nooon*^ 
Referring finally to 10 Parity Check Circuit (lOPC) 23048, lOPC 23048 is connected from IB Bus 23030 to 

to receive each data word, that Is 32 bhs of data plus 4 bits of parity, appearing on IB Bus 23030. lOPC 23048 
confirms parity and data validity of each data word appearing on IB Bus 23030 and, in particular, 
determines validity of parity and data of data words written into FlU 20120 from lOS 10116. lOPC 23048 
generates output Parity Error (PER), previously discussed. Indicating a parity error in data words from lOS 

IS Referring to DS 23016, OS 23016 includes Byte Nibble Logic (BYNL) 23050, Parity Rotation Logic (PRL) 
23052, and Bit Scale Logic «SL) 23054. BYNL 23050, PRL 23052, and BSL 23054 may respectively be 
comprised of, for example, 25S10 shifters. BYNL 23050 is connected from IB Bus 23030 for re«iying and 
shifting the 32 data bits of a data word selected and transferred onto IB Bus 23030. PRL 23052 is a 4 bit 
register simllariy connected from IB Bus 23030 to receive and shift the 4 parity bits of a data word selected 

20 and transferred onto IB Bus 23030. Outputs of BYNL 23050 and PRL 23052 are both con^^^^ed onto DSO 
Bus 23032, thus providing a 36 bit HU 20120 data word output <JHrectly from BYNL 23050 and PRL 23052. 
BYNL 23050-8 32 bit data output is also connected to BSL 23054's Input BSL 23054's 32 brt output is in turn 

provided to MSK 230ia ^ . , . uu.f ^ uv^ 

As previously described, DS 23016 performs data manipulation operations involving shifting of bits 

2S within a data word. In general, data shift operations performed by DS 23016 are rotations wherein data bite 
are right shifted, with least significant bits of data word being shifted into most significant bit position and 
. most significant bits being translated towards least significant bit positions. DS 23016 rotation operations 
are performed in two stages. First stage is perfomied by BYNL 23050 and PRL 23052 and emprises right 
rotations on a nibble basis (a nibble is defined as 4 bits of data). That is, BYNL 23050 right ^jfts a data word 

so by an integral number of 4 bit increments. A right rotation on a nibble by nibble basis may, for example, be 
performed when RM 20722 asserts FUPHALF previously described. FUPHALP is asserted for lOS 10116 haH 
word read operations wherein the request data resides in the most significant 16 bits of a data word from 
MC 20116. BYNL 23050 will perform a right rotation of 4 nibbles to transfer the desired 16 bits of data into 
tite least signrficant 16 bits of BYNL2:»)50's ou^ut Resulting BYNR 23050 output, together PRL 230^'s 

3S parity bit output would then be transferred tiirough DSO 23050 to MIO Bus 10129. In addition to perfonriing 
data shifting operations, DS 23016 may transfer a data v«)rd, that is the 32 bits of ^^^^Jf^^ ^ 
23018 when data manipulation to be performed does not require data shifting, that is shifts of 0 bits may be 

^^eSause data bits are shifted by BYNL 2^)50 on a nibble basis, tfie relationship between the 32 data 
40 bits of a word and die corresponding 4 parity bits may be maintained if parity bits are similarly right ro^ed 
by an amount corresponding to right rotation of data bits. This relationship is true if the data word isshifted 
in multiples of 2 nibbles, that is 8 bits or 1 byte. PRL 230S2 right rotates tiie 4 parity bhs of a data word by an 
amount con-eaponding to right rotation of die corresponding 32 data bits in BYNL 23050. Right rotated 
outputs of BYNL 23050 and PRL 23052 ttierofore comprise a valid data word having 32 bits of data and 4 bits 
4S of parity wherein tine parity bits are correctly related to tiie data bits. A right rotated data word output from 
BYNL 23050 and PRL 23052 may be transferred onto DSO Bus 23032 for subsequent transfer to MOD Bus 
10144 or MIO Bus 10129 as described above. DSO 23032 is used as FlU 20120's output data path for byte 
write operations and "rotate read" operations virtierein tiie required manipulation of a particular data word 
requires only an integral numer of right rotations by bytes. Amount of rigtrt rotation of 32 b«s of data in 
60 BYNL 23050 and 4 bits of parity in PRL 23052 is controlled by input signal shift (SHFT) (0--2) to BYNL 23050 
and PRL 23052. As will be described below, SHFT (0—2) is generated, togetiier with SHFT (3-4) controlling 
BSL 23054, by FlUC 23012. BYNL 23050 and PRL 23052, like BSL 23054 described below, are parallel shift 
logic chips and entire rotation operation of BYNL 23050 and PRL 23052 or BSL 23054 may be performed in a 

S$ ^'"^S^Jd stage of rotation is performed by BSL 23054 which, as described above, receives the 32 data 
bits of a data word from BYNL 23050. BSL 23054 perfonns right rotation on a bit by bit basis with the shift 
amount being selectable between 0-3 bits. Therefore, BSL 23054 may rotate bits through nibble 
boundaries. BYNL 23(»0 and BSL 23054 therefore comprise a data shifting circuit capable of performing 
bIt-by-bit right rotation by an amount from 1 bit to a full 32 bit right rotation. 

€0 Refening now to MSK 23018. MSK 23018 is comprised of 5 32 bit Mask Word Generators (MWG s) 
23056 to 23064, MSK 23018 generates a 32 bit outptft to AR 23020 by selectively combining 32 bit mask 
word outputs of MWG's 23056 to 23064. Each mask word generated by one of MWG's Z3056 to 23064 is 
effectively comprised a bit by bit combination of a set of enabling bits and a predetermined 32 bit mask 
word, generated by FlUC 2301 2 and MIC 20122. MWG's 23058 to 23064 are each comprised of for sample, 

65 open collector NAND gates for peritorming tiiese functions, while NWG 23056 is compnsed of a PROM. 
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As just described, outputs of M WG's to 23064 are all open collector circuits so that any selected 
combination of ma^ word outputs from MWG's 23056 to 23064 may be ORed together to comprise the 32 
bh output of MSK 23018. 

MWG 23056 to MWG 23064 generate, respectively, mask word outputs Locked Bit Word (LBW) (0—31), 

5 Sign Extended Word (SEW) (0—31), Data Mask Word (DMW) (0—31), Blank Rll Word (BWF) (0—31), and 
Assembly Register Output (ARO) (0—31). Referring first to MWG 23064 and ARO (0—31), the contents of 
Assembly Register (ASYMR) 23066 in AR 23020 are passed through MWG 23064 upon assertion of enabling 
signal Assembly Output Register (ASYMOR). ARO (0—31) is thereby a copy of the contents of ASYMR 
23066 and MWG 23064 allows the contents of ASYMR 23066 to be ORed with the selected combination of 

w LBW (0-31 >, SEW (0-31 ), DMW (0—31 ), or W=W (0-31 ). 

DMW (0—31) from MWG 23060 is generated by ANDing enable Input Data Mask (OMSK) (0—31) whh 
the 32 bit output of DS 23016. OMSK (0—31) is a 32 bit enabling word generated, as described below, by 
FlUC 23012. FIUC 2301 2 may generate 4 different OMSK (0—31 ) patterns. Referring to Fig. 231, the 4 DMSKs 
(0-31 ) which may be generated by FIUC 20132 are shown. DMSKA (0—31) is shown in Une A of Rg. 231. In 

7S DMSKA (0—31 ) all bits to the left of but not including a bit designated by Left Bh Address (LBA) and all bits 
to the right of and not Induding a bit designated by Right Bit Address (RBA) are 0. All bhs between, and 
including, those bits designated by LBA and RBA are 1's. DMSKB (0—31) is shown in Line B of Rg. 231 and 
IS DMSKA (0-31) inverted. DMSKC (0—31) and DMSKD (0—31) are shown, respectwely, in Unes C and D of 
Rg. 231 and are comprised of, respectively, all Cs or all I's. As stated above OMSK (0—31) is ANDed with 

20 the 32 brt output of DS 2301 a As such, DMSKC (0-31) may be used, for example, to inhibit DS 23016*3 
output while DMSKD (0—31) may be used, for example, to pass DS 23016's output to AR 2^20. DMSKA 
(0—31) and DMSKB (0--31) may be used, for example, to gate selected portions of DS 23016^$ output to AR 
23020 where, for example, the selected portions of DS 23016*8 output may be ORed with other mask word 
outputs MSK 230ia 

2S Referring nextto MWG 23062, MWG 23062 generates BFW (0—31). BFW (0—31) is used in a particular 
operation wherein 32 bit data words containing 1 to 4 ASQI blanks are required to be g^ierated wherein 1 
bit/byte contains a logic one and remaining bits contain logic zeros. In this case, the ASCII blank bytes may 
contain logic 1's In bit positions 2, 10, 18, and 26. 

RefeiTtng again to Rg. 231, Line E therein shows 32 bit right mask (RMSK) (0—31) which may be 

30 generated by RUC 23012. In the most general case, RMSK contains zeros in all bit positions to the left of 
and mciuding a bit position cfesignated by RBA. When used In a blank fill operation, bit portions 2, 10, 18, 
and 26 may be selected to contain logic Vs depending upon those byte positions containing logic 1's, that 
b in tho^ bytes containing ASCII blanks; these bytes to the right of RBA are determined by RMSK (0—31). 
RMSK (0—31) is enable! through MWG 23062 as BWF (0—31) when MWG 23062 is enabled by blank fill 

3s (BLNKRLU provided from RU 2301 2. 

As descn"bed above, MWG's 23058 to 23064 and in particular MWG's 23060 and MWG 23062 are NAND 
gate operations. Tlierefore, the outputs of MWGs 23056 through 23064 are active low signals. The inverted 
output of ASYMR 23(XB is used as an output to ASYRO 23034 to Invert these outputs to active high, 
MWG 23058, generating SEW (0—31), Is used In generating sign extended or filled words. In sign 

4Q extended words, all bit spaces to tiie left of the most significant bit of a 32 bit data word are filled with the 
sign bit of the data contained therein, the left most bits of the 32 bit word are filled with 1 's or O's depending 
on whether ttiat word's sign bit indicates that the data contained therein is a positive or negative number. 

Sign Select Multiplexor (SIGNSEU 23066 is connected to receh^e the 32 data bits of a word present on 
IB Bus 23030. Sign Select (SGNSEL) (0-^1 to SIGNSEL 23066 is derived fnom SBA (0--4), that is from SBA 

45 Bus 21226 from PRMUX 20720. As previously described, SBA (0-4) is Starting Bit Address identifying the 
first or most significant bit of a data word. When a data word contains a signed number, most significant bit 
contains sign bit of that number. SGNSEL (0--4) input to SIGNSEL 23066 is used as a selection input and, 
when SIGNSEL is enabled by Sign Extend (SIGNEXT) from FlU 23012, selects tiie sign bit on IB Bus 23030 
and provides tiiat sign bK as an Input to MWG 2305a 

so Sign bit input to MWG 23058 is ANDed witfi each bit of left hand mask (LMSK) (0—31 ) from FIUC 23012. 

Refemng again to Rg. 231, LMSK (0—31) is shown on Line F thereof. LMSK (0—31) contains all O's to the 
right of and including the bit space identified by LBA and Vs in all bit spaces to the left of that bit space 
Identified by LBA. SEW (0—31) will therefore contain sign bit in all bit spaces to the left of the most 
sign'rficant bit of the data word present on output of MWG 23058. The data word on IB Bus 23030 may then 

ss be passed through DS 23016 and subjected to a OMSK operation wherein all bits to the left of the most 
agnificant bit are forced to 0. SEW (0—31 ) and DMW (0—31 ) outputs of MWG's 23058 and 23060 may then 
be ORed to provide the desired find extended word output 

LBW (0—31), provided by MWG 23056, Is used in locked bit operations wherein the most significant 
data bit of a data word is in MEM 1 01 12 forced to logic 1, SIGNSEL (0-4) is an address inputto MWG 23056 

60 and, as previously described, indicates most significant data bit of a data word present on an IB Bus 23030. 
MWG 23056 is enabled by input Lock (LOCK) from RUC 23012 and the resulting LBW (0-^1) will contain a 
single logic 1 in the bit space of the most significant data bit of the data word present on IB Bus 23030. The 
data word present on IB Bus 23030 may then be passed through DS 23016 and MWG 23060 to be ORed with 
LBW (0—31) so that that data words most a'gnificant data Wt Is forced to logic 1. 

6s Referring to AR 23020, AR 23020 includes ASYMR 23066, which may be comprised for example of a 
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SN74S175 registers, and Assembly Register Parity Generator <ASYPG) 23070. As previously described, 
ASYMR 23066 is connected from IVISK 23018 32 bit output. A 32 bit word present on MSK 23018's output 
will be transferred Into ASYiVIR 23066 when ASYMR 23066 is enabled by Assembly Register Load 
(ASYMLD) from MIC 2012Z The 32 bit word generated through DS 23016 and MSIC 23018 will then be 

^* present on ASYRO Bus 23034 and may, as described above, then be transferred onto MOD Bus 10144 or 
MIO Bus 10129, ASYPG 23070 is connected from ASYMR 23066 32 bft output and will generate 4 parity bits 
for the 32 bit word presently on the 32 data lines of ASYRO Bus 23034. ASYPG 23070*8 4 bit parity output Is 
bused on the 4 parity bit lines of ASYRO Bus 23034 and accompany the 32 bit data word present thereon. 
Having described structure and operation of Data Manipulation Circuitry 23010, FlUC 23012 vinll be 

^0 described next below. . ^ . nn. ♦ 

Referring again to Rg. 230, RUC 23012 provides pipelined microinstruction control of FlU 20120. That 
Is, control signals are received from MIC 20122 during a first clock cyde and certain of the control signals 
are decoded by microinstruction logic to generate further RUC 23012 control signals. During the second 
clock cycle, control signals receh^ed and generated during first clock cyde are provided to DMC 23010, 
some of which are further d«:oded to provide yet other control signals to control operation of FlUC 2301 2. 
FlUC 23012 includes Initial Decode Logic (IDL) 23074, Pipeline Registers (PPLR) 23072, Rna! Decoding Logic 
(FDU 23076, and Enable Signal Pipeline Register (ESPR) 23098 with Enable Signal Decode Logic (ESDL) 
23099. 

IDL 23074 and Control Pipeline Register (CPR) 23084 of PPLR 23072 are connected from control outputs 
^ of MIC 20122 to f^ceive control signals therefrom during a first dock cyde as described above. IDL 23074 
provides outputs to control pipeline registers Right Bit Address Register (RBAR) 23086, Left Bit Address 
Register {Ism 23088 and Shm Roister (SHFR) 23090 of PPLR 23072. CPR 23084 and SHFR 23030 provide 
control outputs directly to DMC 23010. As described above these outputs control DMC 23010 during second 
dodc cyde. 

2B CPR 23084, RBAR 23086, and LBAR 23088 provide outputs to FDL 23076 during second dock cyde and 
FDL 23076 in turn provides certain outputs directly to DMC 23010. 

ESPR 23098 and ESDL 23099 receive enable and control signals from MIC 20122 and in turn provide 
enable and control signals to DMC 23010 and certain other portions of MEM 10112 drcuitry. 

IDL 23074 and FDL 23076 may be comprised, for example, of PROMs. CPR 23084, RBAR 2M86, LBAR 

30 23088, SHFR 23<^, and ESTO 23098 may be comprised, for example, of SN74S194 registers. ESDL 23099 
may be comprised of, for example, oompabble decoders, such as logic gates. 

Referring first to IDL 23074, IDL 23074 performs an initial decoding of drcuitry control signals from MIC 
20122 and prowdes further control signals used by FlUC 23012 In controlling FlU 20120. IDL 23074 is 
comprised of read-only memory arrays Right Bit Address Decoding Logic (RBACH.) 23078, Left Bit Address 

3S Decoding Logic (LBADU 23080, and Shift Amount Decoding Logic (SHFAMTDL) 23082. RBADL 23078 
receives, as address inputs. Final Bit Address (FBA) (0-^, Bit Length Number (BLN) (0-4), and Starting Bit 
Address (SBA) <0— 4). FBA, BUS! and SBA define, respecth/ely, the final bit length, and starting bit of a 
requested data hem as previously discussed with reference to PRMUX 20720. RBADL 23078 also receives 
chip select enable signals Address Translation Chip Select (ATCSJ 00, 01, 02, 03, 04, and 15 from MIC 20122 

^ and, in particular, RM 20722. When FlU 201 20 is required to execute certain MSK 23018 operations. Inputs 
FBA (0—4), BLN (0—4), and SBA (0—4); together with an ATCS input, are provided to RBADL 23078 from 
MIC 20122. RBADL 23078 in tum provides output RBA (Right Bit Address) (0—4), which has been descrit^ed 
above with reference to DMSK (0—31) and RMSK (0-31). LBADL 23080 is dmilar to RBADL 23078 and is 
provided with inputs BLN (O-^), FBA (0-^), SBA (0-4), and ATCS 06, 07, 08, 09, and 05 from MIC 20122. 

45 Again, for certain MSK 23018 operations, LBADL 23080 will generate Left Bit Address (LBA) (0—4), Which 
has t>een previously discussed above with reference to DMSK (0—31) and LMSK (0—31). 

RBA (0-4) and LBA (0—4) are, respecdvely, transferred to RBAR 23086 and LBAR 23088 at start of 
second dock cyde by Pipeline Load Enable signal PIPELD provided from MIC 201 22. RBAR 23086 and LBAR 
23088 in turn respectively provide outputs Register Right Address (RRAD) (0-^1 and Register Uft Address 

50 (RLAD) (0—4) as address inputs to Right Mask Decode Logic (RMSKDL) 23092, Left Mask Decode Logic 
(LMSKDL) 23094, and FDL 23076 at start of second dock cyde. RRAD (0—4) and RLAD (0-4) correspond 
respectively to RBA (0—4) and LBA (0-4). . ^ ^ «. A,^ 

RMSKDL 23092 and LMSKDL 23094 are ROM arrays, having, as just described, RRAD (0-4) and RLAD 
(0—4) as, respectively, address inputs and Mask Enable (MSKENBU from CPR 23084 as enable inputs, 

55 Together, RMSKDL 23092 and LMSKDL 23094 generate, respectively, RMSK (0—31) and LMSK (0—31) to 
MSK 23018. RMSK (0—31) and LMSK (0—31) are provided as inputs to Exdusive Or/Exclusive Nor gating 
(XOR/XNORl 23096- XOR/XNOR 23096 also receives enable and selection signal Out Mask (OUTMSK) from 
CPR 23084. RMSK (0—31 ) and LMSK (0—31 ) inputs to XOR/XNOR 23096 are used, as selected by OUTMSK 
from CPR 23084, to generate a selected DMSK (0—31) as shown in Rg. 231. DMSK (0-31) output of XOR/ 

60 XNOR 23096 is provided, as described above, to MSK 23018. 

Referring again to IDL 23074. SHFAMTBL 23082 decodes certain control inputs from MIC 20122 to 
generate, through SHFR 23090, control inputs SHFT (0-4) and SGNSEL (0-4) to, respectiveiy, DS 23016, 
SIGNSEL 23068 and MWG 23056. Address inputs to the PROMs comprising SHFAiVrTBL 23082 indude FBA 
(0-4), SBA (0— 4J, and FLIPHALF (FUPHALF) from MIC 20122. FBA (0-4) and SBA (O-^) have been 

65 described above. FUPHALF Is a control signal indicating that, as described above, that 16 bits of data 
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requested by lOS 10116 resides in the upper half of a 32 bit data word and causes those 16 bits to be 
transferred to tiie lower half of FlU 201 20's output data word onto MIO Bus 1 01 29, MIC 201 22 afeo provides 
chip enable signals ATCS 10, 11, 12, 13, and 14. Upon receiving these control inputs from MIC 20122, 
SHFAMTDL 23082 generates an output shift amount (SHFAWTT) (0—4) which, together with SBA (0—4) from 
« MIC 20122, is transferred into SHFR 23090 by PIPEU) at start of second clock cycle. SHFR 23090 then 
provides corresponding outputs SHFT (0—4) and SIGNSEL (0—4). As described above, SIGNSEL (0—4) are 
provided to SIGNSEL 23068 and MWG 23056 and MSK 230ia SHFT (0-^) is provided as SHFT (0—2) and 
SHFT (3--4) to, respectively, BYNL 23050 and BSL 23054 and DS 23016. 

Referring to CPR 23(»4, as described above certain control signals are provided directly to FlU 20120 
10 circuitry vwthout being decoded by IDL 23074 or FDL 23076. Inputs to CPR 23084 include Sign Extension 
(SIGNEXT) and Lock (LOCK) indicating, respectively, that HU 20120 is to perform a sign extension 
operation through MWG 23058 or a lock bit word operation through MWG 23056. CPR 23084 provides 
corresponding outputs SIGNEXT and LOCK to MSK 23018 to select these operations. Input Assembly 
Output Register (ASYMOR) and Blank Fill (BLANKFILL) are passed through CPR 23084 as ASYMOR and 
« BLANKRLL to, respectively, R/IWG 23064 and MWG 23062 to select the output of ASYMR 23066 as a mask 
or to indicate that MSK 23018 is to generate a blank filled word through MWG 23062. Inputs OUTMSK and 
MSKENBL to CPR 23084 are provided, as discussed above, as enable signals OUTMSK and MSKENBL to, 
respectively, EXOR/ENOR 23096 and RMSKDL 23092 and LMSKBL 23094 and generating RMSK (0—31), 
LMSK (0-31), and OMSK (0—31) as described above. 
z» Refenring finally to ESPR 23098 and ESDL 23099, ESPR 23098 and PPLR 23072 together comprise a 
pipeline register and ESDL 23099 decoding logic for providing enable signals to FlU 20120 and other MEM 
10112 drcuitry. ESPR 23098 recedes Inputs Drive MOD Bus (DRVMOD) (0-1), Drhre MID Bus (DRVMIO) 
(0--^), and Enable Register (ENREG) (0—1] from MIC 20122 as previously described. DRVMOD (0—1), 
DRVMIO <0— 1), and ENREG (0—1) are transferred into ESPR 23098 by PIPELD as previously described with 
25 reference to PPLR 23072. ESPR 23098 provides corresponding outputs to ESDL 23099, vvhich In turn 
decodes DRVMOD (0—1), DRVMIO (0—1), and ENREG (0-1) to provide enable ^nals to FlU ^120 and 
other MEM 10112 circuitry. Outputs DRVSHFMOD, OTVASYMOD, DRVSHFMIO, and DflVASYMIO are 
provided to DSMOD 23036, DSMIO 23038, ASYMOD 23040, ASYMIO 23042, and FlUlO 23014 to control 
transfer of FlU 20120 manipulated data words onto MOD Bus 1 0144 and MIO Bus 101 29. Outputs lARMEO, 
30 JWDEO, IWDEO, and RIDEO are provided as output enable signals to lARMR 23044, JWDR 23022, IWDR 
23024, and RIDR 23026 to transfer the contents of these registers onto IB Bus 23030 as previously 
descnlDsd. Outputs DRVCAMOD, DRVAMIO, DRVBYMOD, and DRV6YMIO are provided to MC 20116 for 
use in controlling transfer of information onto MOD Bus 10144 and MIO Bus 10129. 

Having descnl^ed the structure and operation of MEM 101 12 alx>ve, the structure and operation of FU 
3S 10120 will be described next below. 

B- Fetch Unit 10120 (Rgs. 202, 206i 101, 103, 104, 238) 

As has been previously described, FU 10120 is an independently operating, microcode controlled 
machine comprising, together with EU 10122, CS 10110*5 micromachine for executing user's programs. 

^ Principal functions of FU 10120 include: (1 ) Fetching and interpreting instnjctions, that is SINs comprising 
SOPs and Names, and data from MEM 10112 for use by FU 10120 and EU 10122j (2) Organizing and 
controlling flow and execution of user programs; (3) Initiating EU 10122 operations; (4| Performing 
arithmetic and logic operations on data; (5) Controlling transfer of data from FU 101^ and EU 10122 to 
MEM 10112; and, (6) Maintaining certain stack register mechanisms. Among these stack and register 

45 mechanisms are Name Cache (NC) 10226, Address Translation C:ache (ATC) 10228, Protection Cache (PC) 
10234, Architectural Base Registers (ABRs) 10364, Micro-Control Registers (mCRs) 10366, Micro-Stack 
(MIS) 10368, Monitor Stack (MOS) 10370 of General Register Rle (GRF) 10354, Micro-Stack Pointer Register 
Mechanism (MISPR) 10356, and Return Control Word Stack (ROWS) 10358. In addition to maintaining these 
FU 10120 resident stad< and register mechanisms, FU 10120 generates and maintains, in whole or part, 

so certain MEM 10112 resident data structures. Among these MEM 101 12 resident data structures are Memory 
Hash Table (MHT) 10716 and Memory Frame Table (MFT) 10718, Woricing Set Matrix (WSM) 10720, Virtual 
Memory Management Request Oueue (VMMRQ) 10721, Active Object Table (AOT) 10712, Active Subject 
Table (AST) 10914, and Virtual processor State Blocks (VPSBs) 10218. In addition, a primary function of FU 
10120 is the generation and manipulation of logical descriptors which, as previously described, are the 

55 basis of CS 10110's internal addressing structure. As will be described further below, while FU 10120's 
internal structure and operation allows FU 10120 to execute arithmetic and logic operations, FU 10120's 
structure includes certain features to expedite generation and manipulation of logical descriptors. 

Referring to Ro- 202, a partial block diagram of FU 10120 is shown. To enhance clarity of presentation, 
certain interconnections within FU 10120, and between FU 10120 and EU 10122 and MEM 10112 are not 

69 shown by fine conriections but, as described further below, are otherwise indicated, such as by common 
signal names. Major functional elements of FU 10120 include Descriptor Processor (DESP) 20210, MEM 
10112 Interfece Logic (MEMINT) 20212, and Fetch Unit Control Logic (FUCTU 20214. DSP 20210 is, in 
general, an arithmetic and logic unit for generating and manipulating entries for MEM 10112 and FU 10120 
resident stack mechanisms and caches, as described above, and. in particular, for generation and 

65 manipulation of logical descriptors. In addition, as stated above, DSP 20210 is a general purpose Central 
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Processor Unit (CPU) capable of performing certain arithmetic and logic functions. 

DESP 20210 includes AON Processor (AONP) 20216, Offset Processor (OFFP) 20218, Length Processor 
(LENP) 20220. OFF=P 20218 comprises a general, 32 bit CPU with additional structure to optimize generation 
and manipulation of offset fields of logical descriptors. AONP 20216 and LENP 20220 comprise, 

5 respccth/^ly, processors for generation and manipulation of AON and length fields of logical descriptors 
and may be used in conjuction with OFFP 20218 for execution of certain arithmetic and logical operations. 
DESP 20210 includes GRF 10354, which in turn include Global Registers (GRs) 10360 and Stack Registers 
(SRs) 10362. As prewously described, GR's 10360 Includes ABRs 10364 and mCRs 10366 while SRs 10362 
includes MIS 10368 and MOS 10370. 

w MEMINT 20212 comprises FU 10120's Interface to MEM 10112 for providing Physical De^nptors 
(physical addresses) to MEM 10112 to read SINs and data from and write data to MEM 10112. MEMINT 
20212 includes, among other logic circuitry, MC 10226, ATC 10228, and PC 10234. 

FUCTL 20214 controls fetching of SINs and data from MEM 10112 and provides sequences of 
mlcrolf^tructlons for control of FU 10120 and EU 10122 in response to SOPs. FUCTL 20214 provides Name 
inputs to MC 10226 for subsequent fetching of corresponding data from MEM 10112. FUCTL 20214 
includes, in part, MlSffl 10356, RCWS 10358, Fetch UnH S-lnterpreter Dispatch Table (FUSDTl 11010, and 
Fetch Unit S-lnterpreter Table (FUSriT) 1 1012. 

Having described the cyverall structure of FU 10120, In particular with regard to previous descnptions in 
Chapter 1 of this description, DESP 20210, MEMINT 20212, and FUCTL 20214 will be described in further 

20 detail below, and in that order. 

1. Description Processor 20210 (Rgs. 202, 101, 103, 104, 238, 239) . 

As described above, DESP 20210 comprises a 32 bit CPU for performing all usual arithmetic and logic 
operations on data. In addition, a primary function of DESP 20210 is generation and manipulation of entnes 

2S for, for example. Name Tables (NTs) 10350, ATC 10228, and PC 10234, and generation and manipulation of 
logical descriptors. As previously described, with reference to CS 10110 addressing structure, logical 
descriptors are logical addresses, or pointers, to data stored In MEM 10112. Logical descriptors are used, 
for example, as architectural base pointers or microcontrol pointers in ABRs 10364 and mCRs 10366 as 
shown in Rg. 103, or as linkage and local pointers of Procedure Frames 10412 as shown In Fig. 104. In a 

30 further example, logical descriptors generated by DESP 20210 and corresponding to certain operand 
Names are stored in MC 1 0226, where they are subsequently accessed by those Names appearing in SINs 
fetched from MEM 10112 to provide rapid translation b^ween <H>erand Names and corresponding logical 
descriptors. , - u • 

As has been previously discussed with reference to CS 10110 addressing structure, logical descnptors 

35 provicted to ATU 10228, from DESP 20210 or NC 10226, are translated by ATU 10228 to physical descriptors 
which are actual physical addresses of corresponding data stored In MEM 101 12. That data subsequently is 
provided to JP 10114, and in particular to FU 10120 or EU 10122, tiirough MOD Bus 10144. 

As has been previously discussed with r^erence to MEM 1 01 12, each data read to JP 10114 from MEM 
101 12 may contain up to 32 bits of infomiation. If a particular data item referenced by a logical descriptor 

^ contains more than 32 bits of data, DESP 2021 0 will, as described further below, generate successive logical 
descriptors, each logical descriptor referring to 32 bits or less of Information, until the entire data item has 
been read from MEM 101 12. In this regard, it should be noted that NC 10226 may contain logical descriptors 
only for data items of 255 bits or less in length. All requests to MEM 101 12 for data Hems greater than 32 
bits in length are generated by DESP 20210. Most of data items operated on by CS 101 10 will, however, be 

45 32 bits or less In lengtfi so that NC 10226 Is capable of handling most operand Names to logical descriptor 
translations. 

As described above, DESP 20210 includes AONP 20215, OFFP 20218, and LENP 20220. OFFP 20218 
comprises a general purpose 32 bit CPU with additional logic circuitry for generating and manipulating 
table and cache entries, as described above, and for generating and manipulating offset fields of AON 

so pointers and logical descriptors. AONP 20216 and LENP 20220 comprise logic circuitry for generating and 
manipulating, respectively, AON and length fields of AON pointers and logical descriptors. As indicated in 
Fig. 202, GRF 10354 is vertically divided in three parts. A first part resides in ANOP 20216 and, In additon to 
random data, contains AON fields of logical descriptors. Second and third parts reside, respectively, in 
OFFP 20218 and LENP 20220 and, in addition to containing random data, respectively contain offset and 

» length fields of logical descriptors. AON, Offset, and length portions of GRF 10354 residing respectively In 
AONP 20216, OFFP 20218, and LENP 20220 are designated, respectively, as AONGRF, OFFGRF, and 
LENGRF. AONGRF portion of GRF 10354 is 28 bits wide while OFFGRF and LENGRF portions of GRF 1 0354 
are 32 bits in width. Although shown as divided vertically into three parts, GRF 10354 is addressed and 
operates as a unitary structure. That is, a particular address provided to GRF 10354 will address 

60 con-esponding horizontal segments of each of GRF 10354's three sections residing In AONP 20216, OFFP 
20218, and LENP 20220. 

a. Offset Processor 20218 Structure 

Referring first to OFFP 2021 8, in addition to being a 32 bit CPU and generating and manipulating table 
65 and cache entries and offeet fields of AON pointers and logical descriptors, OFFP 20218 is DESP 20210's 
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primary path for receiving data from and transferring data to MEM 10112. OFFP 20218 indudes Offset Input 
Select Multipiexer JOFFSEL) 20238, OFFGRF 20234, Offset Muitiplexer l-ogic (OFFMUX) 20240, Offset ALU 
(OFFALU) 20242, and Offset ALU A Inputs Multiplexer (OFFALUSA) 20244. 

OFFSEL 20238 has first and second 32 bit data inputs connected from, respecdveiy, MOD Bus 10144 

s and JPD Bus 10142. OFFSEL 20238 has a third 32 bit data input connected from a first output of OFFALU 
20242, a fourth 28 bit data input connected from a fi rst output of AONGRF 20232, and a fiftti 32 bit data input 
connected from OFFSET Bus 20228. OFFSEL 202^ has a first 32 bit output connected to input of OFFGRF 
20234 and a second 32 bit output connected to a first input of OFFMUX 20240. OFFMUX 20240 has second 
and third 32 bit data inputs connected from, respectively, MOD Bus 10144 and JPD Bus 10142. OFFMUX 

w 20240 also has a fourth 5 bit data input connected from Bias Logic (BIAS) 20246 and LENP 20220, described 
further below, and fifth 16 bit data input connected from NAME Bus 20224. Thirty-two bit data output of 
OFFGRF 20234 and first 32 bit data output of OFFMUX 20240 are connected to, respectWely, first and 
second data inputs of OFFALUSA 20244. A first 32 bit data output of OFFALUSA 20244 and a second 32 bit 
data output of OFFMUX 20240 are connected, respectively, to first and second data inputs of OFFALU 

rs 20242. A second 32 bit data output of OFFALUSA 20244 is connected to OFFSET Bus 20228. A first 32 bit 
data output of OFFALU 20242 is connected to JPD Bus 10142, to a first Input of AON Input Select 
Multiplexer (AONSEL) 20248 and AONP 20216, and, as described above, to a third input of OFFSEL 20238. A 
second 32 bit data output of OFFALU 20242 is connected to OFFSET Bus 20228 and third 16 bit output is 
connected to NAME Bus 20224. 

20 

b. AON Processor 20216 Structure 

Referring to AONP 20216, a prinnaiY function of AONP 20216 is that of containing AON fields of AON 
pointers and logical descriptors. In addition, those portions of AONGRF 20232 not otherwise occupied by 
AON pointers and logical descriptors may be used as a 28 bit wide general register area by JP 101 14. These 

■2S portions of AONGRF 20232 may be so used either alone or in conjunction with corre^KHKiing portions of 
OFFGRF 20234 and LENGRF 2023& AONP 20216 includes AONSEL 20248 and AONGRF 20232. As 
previously described, a first 32 bit data input AONSEL 20248 is connected from a first data output of 
OFFALU 20242. A second 28 bit data input of AONSEL 20248 is connected from 28 brt output of AONGRF 
20232 and from AON Bus 20230. A third 28 bit data input of AONSEL 20248 is connected from logic zero, 

30 that is a 28 bit input wherein each input bit Is set to logic zero. Twenty-eight bit data output of AONSEL 
20248 Is connected to data Input of AONGRF 20232. As just descHbed. 28 bit data output of AONGRF 20232 
is connected to second data input of AONSEL 20248, and is connected to AON Bus 20230. 

c Length Processor 20220 Structure 

35 Referring finally to LENP 20220, a primary function of L£NP 20220 is the generation manipulation of 
length fields of AON pointers and physical descriptors. In addition, LENGRF 20236 may be used, in part 
either alone or in conjunction with corresponding address spaces of AONGRF 20232 and OFFGRF 20234, as 
general registers for storage of data. LENP 20220 includes Length input Select Multiplexer {LENSEL) 20^, 
LENGRF 20236. BIAS 20246, and Length ALU (LENALU) 20252. LENSEL 20250 has first and second data 

40 inputs connected from, respectively, LENGTH Bus 20226 and OFFSET Bus 20228. LENGTH Bus 20226 is 
eight data bits, zero filled while OFFSET Bus 20228 is 32 data bits. LENSEL 20250 has a third 32 bit data 
input connected from data output of LENALU 2D252. Thirty-two bit data output of LENSEL 20250 is 
connect«J to data input of LENGRF 20236 and to a first data input of BIAS 20246. Second and third 32 bit 
data Inputs of BIAS 20246 are connected from, respectively. Constant (C) and Literal (L) ou^uts of FUSITT 

45 1 1012 as will be described further below. Thirty-two bits data output of LENGRF 20236 is connected to JPD 
Bus 10142, to Write Length Input (WL) input of NC 10226, and to a first input of LENALU 20252. FWe bit 
output of BIAS 20246 is connected to a second Input of LENALU 20252, to LENGTW Bus 20226, and, as 
pre>^ously described, to a fourth input of OFFMUX 20240. Thirty-two bit output of LENALU 20252 is 
connected, as stated above, to third input of LENSEL 20250. 

SO Having described the overall operation and the structure of DESP 20210, operation of DESP 20210 will 
be described next below in further detaiL 

d. Descriptor Processor 20210 Operation 
a^. Offset Selector 20238 

£5 Referring to OFFP 20218. GRF 10354 includes GR's 10360 and SR's 10362. GR's 10360 In turn contain 
ABR's 10364, mCR's 10366, and a set of general registers. SR's 10362 include MIS 10368 and MOS 10370. 
GRF 10354 is vertically dh/ided into three parts. AONGRF 20232 Is 28 bits wide and resides in AONP 20216, 
LENGRF 10354 is 32 bits wide and resides In LENP 20220, and OFFGRF 20234 is 32 bits wide and resides in 
OFFP 20218. AONGRF 20232, OFFGRF 20234, and LENGRF 20236 may be comprised of Fairchild 93422s. 

60 In addition to storing oflset fields of AON pointers and logical descriptors, those portions of OFFGRF 
20234 not reserved for ABR's 10365, mCR's 10366, and SR's 10362 may be used as general registers, alone 
or in conjunction with corresponding portions AONGRF 20232 and LENGRF 20236, when OFFP 20218 is 
being utilized as a general purpose, 32 bit CPU. OFFGRF 20234 as will be described further below, is 
addressed in parallel with AONGRF 20232 and LENGRF 20236 by address inputs provided from FUCTL 

^ 20214. 
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OFFSEL 20238 is a multiplexer, comprised for example of SN74S244s and SN74S257s, for selecting 
data inputs to be written into selected address locations of OFFGRF 20234. OFFSEL 20238's first data input 
is from MOD Bus 10144 and is the primary path for data transfer between MEM 10112 and DESP 20210. As 
previously described, each data read from MEM 10112 to JP 10114 is a single 32 bit word where between 
^ one and 32 bits may contain actual data. If a data item to be read from MEM 1 0112 contains more than 32 
bits of data, successive read operations are performed until the entire data Item has been transferred. 

OFFSEL 20238'3 second data input is from JPD Bus 10142. As will be described further belpw^ JPD Bus 
10142 is a data transfer path by which data outputs of FU 10120 and EU 10122 are written into MEM 101 12. 
OFFSEL 20238's input of JPD Bus 10142 thereby provides a wrap around path by which data present at 
outputs of FU 10120 or EU 10122 may be transferred back into DESP 20210 for further use. For example, as 
previously stated a first output of OFFALU 20242 is connected to JPD Bus 10142, thereby allowing data 
output of OFFP 20218 to be returned to OFFP 20218 for further processing, or to be transferred to AONP 
20216 or LENP 20220 as will be described further below. In addition, output of LENGRF 20236 is also 
connected to JPD Bus 10142 so that length fields of AON pdnters or phy»cal descriptors, or data, may be 
read from LENGRF 20236 to OFFP 20218. This path may be used, for example* when LENGRF 20236 Is being 
used as a general purpose register for storing data or intermediate results of arithmetic or logical 
operations. 

OFFSEL 20238's tfiird input is provided from OFFALU 20242's output This data path thereby provides a 
wrap around path wherdiyy of^et fields or data residing in OFFGRF 20234 may be operated on and returned 
to OFFGRF 20234, either in the same address location as originally read from or to a different address 
location. OFFP 20218 wrap around path from OFFALU 20242's output to OFFSEL 20238's third Input, and 
thus to OFFGRF 20234, may be utilized, for example, in '^eadlng from MEM 10112 a data item containing 
more than 32 bits of data. As previously described, each read operation fn9m MEM I0112to JP 10114 is of a 
32 bit word wherein between one and 32 bits may contain actual data. Transfer of a data word containing 

^ more than 32 bits is accomplished by performing a succession of read operations from MEM 101 12 to JP 
10114^ For example, if a requested data item contains 70 bits of data, that data item wili be transferred in 
three consecutive read operations. Rrst and second read operations will each transfer 32 bits of data, and 
final read operation will transfer the remaining 6 bits of data. To read a data item of greater than 32 bits 
from MEM 10112 therefore, DESP 20210 must generate a sequence of logical descriptors, each defining a 

^ suocesshre 32 bit segment of that data item. Rnal logical descriptor of the sequence may define a segment 
of less than 32 bits, for example, six tnts as in the example just stated. In each successive physical 
descnptor, offset field must be incremented by value of length field of the preceding physical descriptor to 
define starting addresses of successive data items segments to be transferred. Ijength field of succeeding 
physical descriptors will. In general, remain constant at 32 bits except for final transifer which may be less 

3S than 32 bits. Offset field will thereby usually be incremented by 32 bits at each transfer until final transfer. 
OFFP 20218*8 wrap around data path from OFFALU 20242's output to their input of OFFSEL 20238 may, as 
stated above, be utilized In such sequential data transfer operations to write Incremented or decremented 
offset field of a current physical descriptor back Into OFFGRF 20234 to offset field of a next succeeding 
physical descriptor. 

<o In 8 further example, OFFP 20218's wrap around path from OFFALU 20242's output to third input of 

OFFSEL 20238 may be used in resolving Entries in Name Tables 10350, that is Name resolutions. In Name 
resolutions, as previously described, offset fields of AON pointers, for example Linkage Pointers 10416, are 
successively added and subtracted to provide a final AON pointer to a desired data Item. 

OFFSEL 20238's fourth input, from AONGRF 20232's output, may be used to transfer data or AON fields 

45 from AONGRF 20232 to OFFGRF 20234 or OFFMUX 20240. This data path may be used, for example, when 
OFFP 20218 is used to generate AON fields of AON pointers or physical descriptors or when perfonning 
Name evaluations. 

Finally, OFFSEL 20238's fifth data input from OFFSET Bus 20228 allows offset fields on OFFSET Bus 
20228 to be written into OFFGRF 20234 or transferred into OFFMUX 20240. This data path may be used, for 
BO example, to copy offset fields to OFFGRF 20234 when JP 10114 is performing a Name evaluation. 

Referring now to OFFMUX 20240, OFFMUX 20240 Includes logic circuitry for manipulating individual 
bits of 32 bit words. OFB^UX 20240 may be used, for example, to increment and decrement offset fields by 
length fields when performing string transfers, and to generate entries for, for example, MHT 10716 and 
MFT 10718. OFFMUX 20240 may also be used to aid in generating and manipulating AON, OFFSET, and 
& LENGTH fiekls of physical descriptors and AON pointers. 

b.b. Offset Multiplexer 20240 Detailed Structure (Fig. 238) 
Refemng to Rg. 238, a more detailed, partial block diagram of OFFMUX 20240 is shown. OFFMUX 
20240 includes Offset Multiplexer Input Selector (OFFMUXIS) 23810, which for example may be comprised 
so of SN74S373S and SN74S244s and Offeet Multiplexer Register (OFFMUXR) 2381 2, which for example may 
be comprised of SN74S374S. OFFMUX 20240 also Includes Reld Extraction Circuit (FEXT) 23814, which 
may for example be comprised of SN74S257St and Offset Multiplexer Reld Selector (OFFMUXFS) 23816, 
which for example may be comprised of SN74S^7s and SN74S374S. Rnally, OFFMUX 20240 includes 
Offset Scaler (OFFSCALE) 23818, which may for example be comprised of AMD 25$10s, Offset Inter- 
6S element Spacing Encoder (OFRESENC) 23820, which may for example be comprised of Falrchild 93427s 
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and Offset Multiplexer Ou^ut Selector (OFFMUXOS) 23822, which may for example be comprised of AMD 
25Ss, Fairdiild 93427s, and SN74S244S. 

Referring first to OFFMUX 20240's connections to other portions of OFFP 20218, OFFMUX 2024O's first 
data input, from OFFSEL 20238, is connected to a first input of OFFMUXIS 238ia OFFMUX 2024O's second 

^ input from MOD Bus 10144, is connected to a second input of OFFMUXIS 23810. OFFMUX 20240's third 
input, from JPD Bus 1 0142, is connected to a first input of OFFMUXFS 2381 6 while OFFMUX 20240'$ fourth 
input from BIAS 20246, is connected to a first input of OFFiyiUXOS 23822, OFFMUX 20240's fifth input, 
from NAME Bus 20224, is connected to a second input of OFFMUXFS 23816. OFFMUX 20240's first output, 
to OFFALUSA 20244, is connected from output of OFFMUXR 23812 whUe OFFMUX 20240's second output 

7^. to OFFALU 2024^ Is connected from output of OFFMUXOS 23822. 

Referring to OFFMUX 20240's internal connections, 32 bit output of OFFMUXIS 23810 is connected to 
input OFFMUXR 23812 and 32 bit output of OFFMUXR 23812 is connected, as described above, as first 
output of OFFMUX 20240, and as a third Input of OFFMUXFS 23816, Thirty-two bit output of OFFMUXR 
23812 is also connected to input of FEXT 23814. OFFMUXFS 23816's first second and third inputs are 
, connected as described above. A fourth input of OFFMUXFS 23816 is a 32 bit input wherein 31 bits are set 
to logic zero and 1 bit to logic 1 . A fifth input Is a 32 bit input wherein 31 bits are set to logic 1 and 1 to logic 
0. A sixth input of OFFMUXFS 23816 is a 32 bit literal (U input provided from FUSITT 11012 and is a 32 bit 
binary number comprising a part of a mlcroinstniction FUCTL 20214, described below. OFFMUXFS 23816's 
seventh and ^ghth Input are connected from FEXT 23814. Input 7 comprises RU end TYPE fields of Name 

20 Table Entries which have been read into OFFMUXR 23812. Input 8 Is a general purpose Input conveying bits 
extracted from a 32 bit word captured in OFFMUXR 23812. As indicated in Rg. 238, OFFMUXFS 23816's 
first third, fourth, fifth, and sixth inputs are each 32 bit inputs which are divided to provide two 16 bit inputs 
each. That Is, each of these 32 bit inputs is divided into a first input comprising bit 0 to 1 5 of that 32 bit input 
and a second input comprising bits 16 to 31. 

2S Thirty^two bit output of OFFMUXFS 2381 6 is connected to inputs of OFFSCALE 2381 8 and OFFIESENC 

23820. As indicated in Fig. 238, Field Select Output (FSO) of OFFMUXFS 23816 fe a 32 bit word divided into a 
first word Including 0 to 15 and a second word including bits 16 to 31. Output FSO of OFFMUXFS 23816, as 
will be described further t^elow, thereby reflects the divided structure of OFFMUXFS 23816's first third, 
fourth, fifth, and sixth inputs. 

^ Logical functions performed by OFFMUXFS 23816 in generating output FSO, and which will be 

described In further detail in following descriptions, include: 

(1) Passing the contents of OFFMUXR 23812 directly through OFFMUXFS 23816; 

(2) Passing a 32 bit word on JPD Bus 10142 directly through OFFMUXFS 23816: 

(3) Passing a literal value comprising a part of a microlnstrucdon from FUCTL 20214 directly through 
35 OFFMUXFS 23816; 

(4) Forcing FSO to be literal values 0000 0000; 

(5) Forcing FSO to be Rteral value 0000 001 ; 

(6) Extracting Name Table Entry fields; 

(7) Accepting a 32 bit word from OFFMUXR 23812 or JPD Bus 10142, or 32 bits of a microinstruction 
^ from FUCTL 20214, and passing the lower 16 bits while fordng the upper 16 bits to logic 0; 

(8) Accepting a 32 bit word from OFFMUXR 23812 or JPD Bus 10142, or 32 bits of miroinstrudibn from 
FUCTL 20214, and passing the higher 16 bits while forcing the lower 16 bits to logic 0; 

(9) Accepting a 32 bh word from OFFMUXR 2^12, or JPD Bus 10142, or Name Bus 20224, or 32 bits of a 
microinstruction from FUCTL 20214, and passing the lower 16 bits while sign extending bit 16 to the upper 

4S 16 bits; and, 

(10) Accepting a 32 bit word from Name Bus 20224 and passing the lowest 8 bits while sign extending 
bit 24 to the highest 24 bits. 

Thirty-two bit output of OFFSCALE 23818 and 3 bit output of OFFIESENC 2:^20 are conne<*ed, 
respectively, to second and third Inputs of OFFMUXOS 23822. OFFMUXOS 23822'8 first input is, as 
so described above, OFFMUX 20240's fourth input and Is connected fit>m output BIAS 20246. Rnally, 
OFFMUXOS 23822's 32 bit output OFFMUX (0—31) is OFFMUX 20240's second output and as previously 
described as connected to a second input of OFF/U.U 20242. 

&C. Offset Multiplexer 20240 Detailed Operation 
ss a.a.a. InterrmI Operation 

Having described the structure of OFFMUX 20240 as shown In Rg. 238, operation of OFFMUX 20240 
will be described below. Internal operation of OFFMUX 20240, as shown In Hg. 238, will be described first, 
followed by description of OFFMUX 20240*6 operation with regard to DESP 20210. 

Referring first to 0I7MUXR 23812, OFFMUXR 23812 is a 32 bit register receiving either a 32 bit word 
60 from MOD Bus 10144, MOD (0-^1), or a 32 bit word received from OFFSEL 20238, OFFSEL (0—31), and is 
selected by OFFMUXIS 23810. OFFMUXR 23812 in turn pro>ddes those selected 32 bit words from MOD Bus 
10144 or OFFSEL 20238 as OFFMUX 20240's first data output to OFFALUSA 20244, as FEXT 23814's input 
and as OFFMUXFS 23816's third input OFFMUXR 23812'a 32 bit output to OFFMUXFS 23816 is provided as 
two parallel 16 bit words designated as OFFMUXR output (OFFMUXRO) (0—15) and (16—31). As described 
S5 above, OFFMUXFS 23816's output to OFFALUSA 20244 from OFFMUXR 23812 may be right shifted 16 
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places and the highest 16 bits zero filled. 

FEXT 23814 receives OFFMUXRO (0-15) and (16—31) from OFFMUXR 23812 and extracts certain 
fields from those 16 bit words. In particular, FEXT 23814 extracts RU and TYPE fields from NT 1 0350 Entries 
which have been transferred Into OFFMUXR 23812. FEXT 23814 may then provide those FlU and TYPE 

^ fields as OFFMUXFS 23816's seventh Input FEXT 23814 may, selectively, extract certain other fields from 
32 bit words residing in OFFMUXR 23812 and provide those fields as OFFMUXFS 23816's eighth Input 

OFFMUXFS 23816 operates as a multiplexer to select certain fields from OFFMUXFS 23816's eight 
inputs and provide corresponding 32 bit output words. Field Select Output (FSO), comprised of those 
selected fields from OFMUXFS 23816'b inputs. As previously described, FSO Is comprised of 2, parallel 1 6 
bit words, f=SO (0—15) and FSO <16-31». Correspondingly, OFFMUX 20240's third input from JPD Bus 
10142, is a 32 bft input presented as two 16 bit words. JPD {0—15) and JPD (16—31). Similarly, OFFMUXFS 
23816's fourth, fifth, and ^xth Inputs are each presented as 32 bit words comprised of 2, parallel 16 bit 
words, respectively, "0" (0-15) and (16-31), "1" (0—15) and (16-31), and L (0-15) and (16-^1). 
OFFMUXFS 23816's second input, from NAME Bus 20224, is presented as a single 16 bh word, NAME 
(16-31 ), while OFFMUXFS 2381 6's Inputs from FEXT 23814 are each less than 16 bits In wdth. OFFMUXFS 
2381 6 may, for a single 32 bit output word, select FSO (0—1 5) to contain one of corresponding 1 6 bit Inputs 
JPD (0-15), "0" (0-15), "1" (0-15), or L (0-15). Similarly, FSO (16-^1) of that 32 bit output word may be 
selected to contain one of NAME (16-31 ), JPD (1 6-31 ), 0 (1 6—31 ), 1 (16-31 ), L (16-31 1, or Inputs 7 and 8 
from FEXT 23814. OFFMUXFS 23816 therefore allows 32 bit words, comprised of two 16 bit fields, to be 

^ generated from selected portions of OFFMUXFS 23816's Inputs. 

OFTOUXFS 23816 32 Wt output Is provided as inputs to OFFSCALE 23818 and OFRESENC 23820. 
Referring first to OFRESENC 23820, OFRESENC 23820 Is used, in particular, in resoMng, or evaluating, NT 
10350 Entries (NTEs) referring to arrays of data words. As indicted in Rg- 108, vrard D of an NTE contains 
certain information relating to inter-element spacing (lES) of data words of an array. Word D of an NTE may 

2S be read from MEM 10112 to MOD Bus 10144 and through OFFMUX 20240 to input of OFRESENC 23820. 
, OFRESENC 23820 then examines word D's lES field to determine whether inter-element spacing of that 
array is a binary multiple, that is 1, 2, 4, 8, 16, 32, or 64 bits. In particular, OFFIESENC 23820 determines 
whether 32 bit word D contains logic zeros in the most significant 25 bits and a single logic one in the least 
significant 7 bits, if inter-element spacing is such a binary multiple, starting addresses of data words of that 

30 array may be determined by left shifting of index (lES) to obtain offset fields of physical addresses of words 
in the array and a slower and more complex multiplication operation is not required. In such cases, 
OFRESENC generates a first output, lES Encodeable (lESENC) to FUCTL 20214 to Indicate that inter- 
element spacing may be determined by simple left shifting. OFFIESENC 23820 then generates encoded 
output Encoded lES (ENCIES), to OFFMUXOS 23822. ENCIES is then a coded value specifying the amount 
' SS of left shift necessary to translate index (iES) value into offsets of words In that array. As indicated in Rg. 
238, ENCIES is OFFMUXOS 23822's third input 

OFFSCALE 23818 is a left shift shift network with zero fill of least significant bits, as bits are left shifted. 
Amount of shift by OFFSCAl£ 23818 is selectable betw/een zero and 7 bits. Thirty-two bit words transferred 
into OFFSCALE 23818 from OFFSCALE 23818 from OFFMUXFS 23816 may therefore be left shifted, bit by 

^ bit to selectively reposition bits within that 32 bit input word. In conjunction with OFFMUXFS 23816, and a 
wrap around connection provided by OFFALU 20242's output to OFFSEL 20238, OFFSCALE 23818 may be 
used to generate and manipulate, for example, entries for MHT 10716, MFT 10718, AOT 10712, and AST 
1(B14, and other CS 10110 data structures. 

OFFMUXOS 23822 is a multiplexer having first, second, and third inputs from, respectively, BIAS 

« 20246, OFFSCALE 23818, OFRESENC 23820. OFFMUXOS 23822 may select any one of these inputs as 
OFFMUX 20240's second output OFFMUX (0—31). As previously described, OFFMUX 20240's second 
output is connected to a second input of OFFALU 20242. 

Having described internal of OFFMUX 20240, operation of OFFMUX 20240 with regard to overett 
operation of DESP 20210 will be described next below. 

b.b.b. Operation Relative to Descriptor Processor 20210 
OFFMUX 20240's first input from OFFSEL 20238, allows inputs to OFFSEL to be transferred through 
OFFMUXIS 23810 and into OFFMUXR 23812. This input allows OFFMUXR 23812 to be loaded, under 
control of FUCTL 20214 microinstructions, with any input of OFFSEL 20238. in a particular example, 

SS OFFALU 20242's output may be fed back through OFFSEL 20238's third input and OFFMUX 20240's first 
input to allow OFFMUX 20240 and OFFALU 20242 to perform reiterative operations on a single 32 bit word. 

OFFMUX 20240's second input, from MOD Bus 10144, allows OFFMUXR 23812 to be loaded directly 
from MOD Bus 10144. For example, NTEs from a currently active procedure may be loaded into OFFMUXR 
23812 to be operated upon as described above. In addition, OFFMUX 20240's second input may be used in 

60 conjunction vtnth OFFSEL 20238's first input, fram MOD Bus 10144, as parallel input paths to OFFP 20218. 
These parallel input paths allow prpelsning of OFFP 20218 operations by allowing OFFSEL 20238 and 
OFFGRF 20234 to operate independently from OFFMUX 20240. For example, FU 10120 may initiate a read 
operation from MEM 10112 to OFFMUXR 23812 during a first microinstruction. The data so requested will 
appear on MOD Bus 10144 during a second microinstruction and may be loaded into OFFMUXR 23812 

es through OFFMUX 20240's second input from MOD Bus 10144. Concurrently, FU 10120 may Initiate, at start 
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of second microinstnicdon, an independent operation to be performed by OFf=SEL 20238 and OFf=GRF " 
20234, for example loading output of OFFALU 20242 into OFFGRF 20234. Therefore, by providing an 
independent path into OFFMUX 20240 from MOD Bus 10144, OFFSEL 20238 is free to perform other, 
cjoncurrent data transfer operations while a data transfer from MOD Bus 10144 to OFFMUX 20240 is being 
* performed. 

OFFMUX 20240*5 third input, from JPD Bus 10142, is a general purpose data transfer path. For 
example, data from LENGRF 20236 or OFFALU 20242 may be transferred into OFFMUX 20240 through JPD 
Bus 10142 and OFFMUX 2024O's third input 

OFFMUX 20240's fourth input is connected from BIAS 20246 and primarily used during string transfers 

W as descnT>ed above. That is, length fields of physical descriptors generated for a string transfer may be 
transferred into OFFMUX 20240 through OFFMUX 20240*5 fourth input to increment or decrement offset 
fields of those physical descriptors in OFFALU 20242. 

OFFMUX 20240's fifth input is connet^ed from NAME Bus 20224. As will be described further below. 
Names are provided to NC 10226 by FUCTL 20214 to call, from MC 10226, logical descriptors corresponding 
to Names appearing on MOD Bus 10144 as part of sequences of SINs. 

As each Name is presented to NC 10226, that Name is transferred into and captured in Name Trap (NT) 
20254. Upon occurrence of an NC 10226 miss, that is NC 10226 does not contain an entry corresponding to 
a particular Name, that Name is subsequently transferred from NT 20254 to OFFMUX 20240 through NAME 
Bus 20224 and OFFMUX 20240's ftfth input. That Name, which is previously described as an 8, 12. or 16 bit 

^ binary number, may then be scaled, that is multiplied by a NTE size. That scaled Name may then be added 
to Name Table Pointer (NTPl from mCRs 10366 to obtain the address of a corresponding NTE In an NT 
10350. In addition, a Name resulting in a NC 10226 miss, or a page fault in the corresponding NT 10350, or 
requiring a sequence of Name resoh/es, may be transferred into OFFGRF 20234 from OFFMUX 20240, 
through OFFALU 20242 and OFFSEL 20238 thini input That Name may subsequently be lead, or restored, 

^ from OR=GRF 20234 as required. 

Referring now to outputs of OFFMUX 20240, OFFMUX 20240*6 first output, from OFFMUXR 23812, 
allows contents of OFFMUXR 2381 2 to be transferred to first input of OFFALU 20242 through OFFALUSA 
20244. OFFMUX 20240's second output from OFFMUXOS 23822, is provided directly to second input of 
OFFALU 20242. OFFALU 20242 may be concurrently provided with a first input from OFFMUXR 23812 and a 

30 second input for example a manipulated offeet field, from OFFMUXOS 23822. 

Refemng to OFFALUSA 20244, OFFALUSA 20244 is a multiplexer. OFFALUSA 20244 may select either 
output of OFFGRF 20234 or first output of OFFMUX 20240 to be either firet Input of OFFAUU 20242 or to be 
OFFP 20218's output to OFFSET Bus 20228. For example, an offeet field from OFFGRF 20234 may be read to 
OFFSET Bus 20228 to comprise offeet field of a current logical descriptor, and concurrently read Into 

35 OFFALU 20242 to be incremented or decremented to generate offeet field of a subsequent logical 
descriptor in a string transfer. 

OFFALU 202^ is a general purpose, 32 bit arithmetic and logic unit capable of perfonmtng all usual 
ALU operations. For example, OFFALU 202A2 may add, subtract increment or decrement offeet fields of 
logical descriptors. In addition, OFFALU 20242 may serve as a transfer path for data, that is OFFALU 20242 

^ may transfer input data to OFFALU 20242^$ outputs without operating upon that data, OFFALU 20242's first 
output as described above, is connected to JPD Bus 10142, to third input of OFFSEL 20238, and to first 
Input of AONSEL 2024a Data transferred or manipulated by OFFALU 20242 may therefore be transferred 
on to JPD Bus 10142, or wrapped around into OFFP 20218 through OFFSEL 20238 for subsequent or 
reiterative operations. OFFALU 20242's output to AONSEL 20248 may be used, for example, to load AON 

<s fields of AON pointers or physical descriptors generated by OFFP 20218 into AONGRF 20232. In addition, 
tfiis data path allows FU 10120 to utilize AONGRF 20232 as, for example, a buffer or temporary memory 
space for Intermediate or final results of FU 10120 operations. 

OFFALU 20242's output to OFFSET Bus 20228 allows logical descriptor offs^ fields to be transferred 
onto OFFSET Bus 20228 directly from OFFALU 20242. For example, a logical descriptor offset field may be 

50 generated by OFFALU 20242 during a first clock cyde, and transferred immediately onto OFFSET Bus 20228 
during a second clock cycle. 

OFFALU 20242^8 third output is to NAME Bus 20224. As will be described further below, NAME Bus 
20224 is address input (ADR) to NC 10226. OFFALU 20242's output to NAME Bus 20224 thereby allows 
OFFP 20218 to generate or provide addresses, that is Names, to NC 10226. 

£S Having described operation of OFFP 20218, operation of LENP 20220 will be described next below. 

e- Length Processor 20220 {Rg. 239) 

Referring to Rg. 202, a primary function of LENP 20220 is generation and manipulation of logical 
descriptor length fields, including length fields of logical descriptors generated in string transfers. LENP 
eo 20220 Includes LENGRF 20236, LENSEL 20250, BIAS 20246, and LENALU 20252. LENGRF 20236 may be 
comprised, for example, of Fairchild 93422s. LENSEL 20250 may be comprised of, for example, SN74S257s, 
SN74S157S, and SN74S244s, and LENALU 20252 may be comprised of, for example, SN74S381S. 

As previously described, LENGRF 20236 is a 32 bh wide vertical section of GRF 10354. LENGRF 20236 
operates in parallel with OFFGRF 20234 and AONGRF 20232 and contains, in part length fields of logical 
£5 descriptors. In addition, also as previously described, LENGRF 20236 may contain data 
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LENSEL 20250 is a multiplexer having three inputs and providing outputs to LENGRF 20236 and first 
input of BIAS 20246. liNSEL 20250's first input Is f ronn Length Bus 20226 and may be used to write physical 
descriptor or length fields from LENC3TH Bus 20226 into LENGRF 20236 or into BIAS 20246. Such length 
fields may be written from LENGTH Bus 20226 to LENGRF 20236, for example, during Name evaluation or 
S resolve operations. LENSEL20250's second input Is from OFFSET Bus 20228. LENSEL20250's second mput 
may be used, for example, to load length fields generated by OFFP 20218 into LENGRF 20236. In addition, 
data operated upon by OFFP 20218 may be read into LENGRF 20236 for storage through LENSEL 20250 s 
second Input 

LENSEL 20250's third Input is from output of LENALU 20252 and is a wrap around path to retum output 

to of LENALU 20252 to LENGRF 20256, LENSEL 20250's third input may. for example, be used during string 
transfers when length fields of a particular logical descriptor is incremented or decremented by LENALU 
20252 and returned to LENGRF 20236. This data path may ateo, for example, be used In moving a 32 bit 
vrord from one location In LENGRF 20236 to another location in LENGRF 20236. As stated above, LENSEL 
20250's output is also provided to first input BIAS and allows data appearing at first, second, or third inputs 

IS of LENSEL 20250 to be provided to first input of BIAS 20246. 

BIAS 20246, as will be described In further detail below, generates logical descriptor length fields 
during string transfers. As described above, no more than 32 bits of data may be read from MEM 10112 
during a single read operation. A data Item of greater than 32 bits in length must therefore be transferred in 
a series, or string, of read operations, each read operation transferring 32 tMts or less of data. String transfer 

20 logical descriptor length fields generated BIAS 20246 are provided to LENGTH Bus 20226, to LEN/U.U 20252 
second Input and to OFFMUX 20240'8 fourth input as previously described. These strir^ transfer logical 
dmdptor length fields, r^n^ to as bias fields are provided to LENGTH Bus 20226 by BIAS 20246 to be 
length fields of the series of logical descriptors generated by DESP 20210 to execute a string transfer. These 
bias fields are provided to fourth input OFFMUX 20240 to incrennent or decrement offset fields of those 

25 logical descriptors, as previously described. These bias fields are provided to secorKl input of LENALU 
20252, during string transfers, to correspondingly decnsment the length field of a data Item being read to 
. MEM 101 1 2 In a string transfer. BIAS 20246 will be described in greater d^il below, after LENALU 20252 is 
first briefly described. 

3Q a-a. Ungth ALU 20252 

LENALU 20^ is a general purpose, 32 bit arithmetic and logic unit capable of executing all customary 

arithmetic and logic operations. In particular, during a string transfer of a particular data Item LENALU 

20252 recewes ttrat data items length field from LENGRF 20236 and successive bias fields from BIAS 20246. 

LENALU 20^2 then decrements that logical descriptor's current length field to generate length field to be 
5ff used during next read operation of the string transfer, and transfers new length fieid back into LENGRF 

20236 through LENSEL 20250's third input 

b.b. BIAS 20246 (Fig. 239) 
Referring to Rg. 239, a partial block diagram of BIAS 20246 is shown. BIAS 20246 indudes Bias 

40 Memory (BIASM) 23910, Lengtii Detector (LDET) 2^12, Next 2erx> Detector <NXTZRO) 23914, and Select 
Bias (SBIAS) 2^16. Input of LDET 23912 is first input of BIAS 20246 and connected from output of LENSEL 
20250. Output of LDET 2391 2 is connected to data input of BIASM 2391 0, and data output of BIASM 23910 is 
connected to input of NXTZRO 23914. Output of NXTZRO 23914 is connected to a first input of SBIAS 
2391 6. A second input of SBIAS 23916 is BIAS 20246's second Input L8, and is connected ft^om an output of 

4S FUCTL 20214. A third input of SBIAS 23916 Is BIAS 20246's third input U and is connected from yet another 
output of FUC11 20214. Ou^ut of SBIAS 23916 is output of BIAS 20246 and, as described above, is 
connected to LENGTH Bus 20226, to a second input of LENALU 20262, and to fourth input of OFFMUX 
20240. 

BIASM 23910 is a 7 bit wide random access memory having a length equal to, and operating and 

so addressed In parallel with, SB's 10362 of GRF 10354. BIASM 23910 has an address location corresponding 
to each address location of SR's 10362 and is addressed concurrentiy with those address locations in SR's 
10362. BIASM 23910 may be comprised, for example, of AMD 27S03As. 

BIASM 23910 contains a bias value of each logical descriptor residing in SR's 10362. As described 
above, a bias value is a number representing numl>er of bits to be read from MEM 101 12 in a particular read 

55 operation when a data item having a corresponding logical descriptor, with a length field stored LENGRF 
20236, Is to be read from MEM 10112. Initially, bias values are written into BIASM 23910, in a manner 
described below, when their corresponding length fields are written into LENGRF 20236. If a particular data 
Item has a length of less than 32 bits, that data item's initial bias value vwll represent tliat data Kerns actual 
length. For example, if a data item has a length of 24 bits tiie associated bias value will be a 6 bit binary 

eo number representing 24. That data item's length field in LENGRF 20236 will similarty contain a length value 
of 24, If a particular Item has a length of greater than 32 bits for example, 70 bits as described in a previous 
example, that data item must be read from MEM 10112 in a string transfer operation. As previously 
described, a string transfer is a series of read operations transferring 32 bits at a time from MEM 101 12, 
with a final transfer of 32 bits or less completing transfer of that data Hem. Such a data item's initial length 

05 field entry in LENGRF 20236 will contain, using the same example as previously described, a value of 70. 



65 



EP 0 067 556 B1 



That data item's initial bias entry written into a corresponding address space of BIASM 23910 will contain a 
bias value of 32. That inrtial bias value of 32 indicates that at least the first read operation required to 
transfer that data item from MEM 10112 wt!) transfer 32 bits of data. 

When a data item having a length of less than 32 bits, for example 24 bits. Is to be read from MEM 
* 10112, that data item's bias value of 24 is read from BIASM 23910 and provided to LENGTH Bus 20226 as 
leng^ field of logical descriptor for that read operation. Concurrently, that bias value of 24 is subtracted 
from that data items length field read from LENGRF 20236. Subtracting that bias value from that length 
value will yield a result of zero, indicating that no further read operations are required to complete transfer 
of that data item. 

If a data item having, for example, a length of 70 bits ts to be read from MEM 10112, that data item's 
initial bias value of 32 is read from BIASM 23910 to L£NGTH Bus 20226 as length field of first logical 
descriptor of a string transfer. Concurrently, that data item's initial lengtii field is read from LENGRF 20236. 
That data item's inftial bias value, 32, is subtracted from that data item's initial length value, 70, and 
LENALU 20252. The result of that subtraction operation is the remaining length of data item to be 
transferred in one or more subsequertt read operations;. In this example, subtracting initial bias value from 
initial length value indicates that 38 bits of that.data item remain to be transferred. LENALU 20252's output 
representing results of this subtraction, for example 38, are transfen'ed to LENSEL 20250*3 third Input to 
LENGRF 20236 and written into address location from whfoh that data item's initial lengtfi value was read. 
This new length field entry then represents remaining length of that data item. Concurrently, LDET 23912 

^ examines that residual length value being written into LENGRF 20236 to detmnine whether remaining 
length of that data item is greater than 32 t>its or is equal to or less than 32 bits. If remaining length is 
greater than 32 bits, LDET 23912 generates a next bias value of 32. which is written into BIASM 23910 and 
same address location that held Initial bias value, if remaining data item length is less than 32 bits, LDET 
23912 generates a 6 bit binary number representing actual rematning length of data item to be transferred. 

^ Actual remaining length would then, again, be written into BIASM 23910 address location originally 
containing initial tries value. These operations are also performed fay LDET 23912 in examining initial length 
field and generating a corresponding initial bias value. These read operations are continued as described 
above until LDET 23912 d^ects that remaining length field is 32 bits or less, and thus that transfer of that 
data Hem will be completed upon next read operation. When this event is detected, LDET 23912 generates a 

^ seventh bit input into BIASM 23910, which is written into BIASM 23910 together with last bias value of that 
string transfer. Indicating that remsnning length will be zero after next read operatioru When a final bias 
value Is read fr om B IASM 23910 at start of next read operation of that string transfer, that seventh bit is 
examined by NXTZRO 23914 which subsequently generates a test condition output. Last Read (LSTRD) to 
FUCTL 20214. FUCTL 20214 may then terminate execution of that string trartsfer after that last read 

35 operation, if the transfer has been successfully completed. 

As previously described, the basic unit of length of a data item in CS 1 01 10 is 32 bits. Accordingly, data 
items of 32 or fewer bits may be transferred directly while data items of more than 32 bits require a string 
transfer. In addition, transfer of a data item through a string transfer requires tracking of the transferred 
length, and remaining length to be transferred, of both the data item Itself and the data storage space of the 

^ location the data Item is being transferred to. As such, BIAS 20246 will store, and operate with, in the 
nnanner described above, length and bias fields of the logical descriptors of both the data item and the 
location tiie data item is being transferred to, FUCTL 20214 will receive an LSTRD test condition if bias field 
of source descriptor t>ecomes zero before or concurrently with that of the destination, that is a completed 
transfer, or If bias field of destination becomes zero before that of the source, and may provide an 

^ appropriate microcode control response, ft should be noted that if source bias field becomes zero before 
that of the destination, the remainder of the location that this data item is being transferred to will be filled 
and padded with zeros. If the data item is larger than the destination storage capacity, the destination 
location vnW be filled to capacity and FUCTL 20214 notified to initiate aporopriate action. 

In addition to allowing data item transfers which are insensitive to data item length, BIAS 20246 allows 

so string transfers to be accomplished by short, tight microcode loops which are insensitive to data item 
length. A string transfer, for example, from location A to location B is encoded as: 

(1) Fetch from A, subtract length from bias A, and update offiset and length of a: and, 

(2) Store to B, subtract length from bias B, and branch to (1) if length of B does not go to zero or fall 
through (end transfer} if length of B goes to zero. Source (A) length need r>ot be texted as the microcode 

ss loop continues until length of B goes to zero; as descril>ed above, B will be filled and padded with zeros if 
length of A is less than length of B, or B will be filled and the string transfer ended If length of A is greater 
than or equal to length of B. 

LDET 23912 and NXTZRO 23914 thereby allow FUCTL 20214 to automatically initiate a string transfer 
upon occurrence of a single microinstruction from FUCTL 20214 initiating a read operation by DESP 20210. 

eo That microinstruction initiating a read operation will then be automatically repeated until LST RD to FUCTL 
20214 from NXTZRO 23914 indicates that the string transfer is completed. LDET 23912 and NXTZRO 23914 
nnay, respectively, be comprised for example of S74S260s, SN74S133s, SN74S518, SN74S00s, SN74SO0S, 
SN74S04S, SN74S02S, and SN74S32S. 

Referring finally to SBIAS 23916« SBIAS 23916 is a muttipiexer comprised, for example, of SN74S288s, 

€5 SN74S374S, and SN74S244S. SBIAS 2391^ under microinstruction control from FUCTL20214, selects BIAS 
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20246's output to be one of a Was value from BIASM 23910, L8. or L SBIAS 23916's jnP"!; fr"'^ ^''Jfl^ 
23910. has been described above. SBIAS 23916's second input L8. is provided from FUCTL 20214 and te 8 
bits of a microinstmction provided from FUSITT 11012. SBIAS 23916's second input allows microcode 
selection of bias values to be used in manipulation of length and offset Ael^ds of logical d^cnptors by 
LENALU 20252 and OFFALU 20242, and for generating entries to MC 10226. SBIAS 23916's third input, U is 
similarly provided from FUCTL 20214 and is a decoded length value derived from portions of 
microinstructions in FUSITT 1 1012. These miaocode length values represent certain commonly occ«"mg 
data item lengths, for example length of 1 , 2. 4, 8, 16, 3^ and 64 bits. An L input representing a length of 8 
bits, may be used for example in reading data from MEM 10112 on a byte by byte basis. 

Having described operation of LENP 20220. operation of AONP 20216 win b© described next below. 

f. AON Processor 20216 

As"^ScriSdKjAONP 20216 includes AONSEL20248 and AONGRF 20232. AONGRF 20232 is a 28 
• bit wide vertical section of GRF 10354 and stores AON fields of AON pointers a"*" '«S'^i,<*^"P^°'^- 
AONSEL 20248 is 8 multiplexer for selecting inputs to be written into AONGRF 20232. AONSEL 20248 may 
be comprised, for example of SN74S257s. AONGRF 20232 may be comprised of. for example, FairchiW 

934^22$ 

As previously described. AONGRF 20232-8 output Is connected AON ^s 20230 to a^^^^^ 
fields of AON pointers and logical descriptors to be transferred onto AON Bus 20230 from AONGRF 20232. 
AONGRF 20232-6 output together with a bi-direetional inputfrom AON Bus 20230, is connected to a seamd 
input of AONSEL 20248 and to a fourth input of AONSEL 20238. Thb data path AON fieWs, either 

from AONGRF 20232 or from AON Bus 20230, to be written into AONGRF 20232 or AONGRF 20234, or 
provided as an input to OFI=MUX 2024O. 

b.b. AON Selector 20248 -li- 
AONSEL 20248-8 first Input is, as previously described, connected from output of OFFAUJ 20242 and is 
used, for example, to allow AON fields generated or manipulated by OFFP 20218 t»_be wntten irrto 
AONGRF 20232. AONSEL 20248-8 third input is a 28 bH word Wherein each bit Is a 'WWl AONbtL 
2024rs third input allows AON fields of all zerosto be written into AONGRF 2a^y^^N field ^^^^^^ 

is reserved to iJidicate that corresponding entries In OFFGRF 20234 and l£NGRF 20236 are "ether AON 
pointers nor logical descriptore. AON fields of all zeros are thereby reserved to indicate that corresponoing 
entries in OFFGRF 20234 and LENGRF 20236 contain data. 

In summary, as described above. DESP 20210 includes AONP 20216. OFFP 2021ft and l£NP a^O^ 
OFFP 20218 contains a vertical section of GRF 10354, OFFGRF 20m rtwng offeet fi^^^ 
pointere and logical descriptors, and for containing data to be operated upon by DESP 202'0; »' zpio « 
principal path for transfer of data from MEM 10112 to JP 10114 and is a p"X^'^oSp^2llSS 
and logic unit for performing all usual arithmetic and logic operation. '"J^^^o"' O^^^O^W ndud^ 
circuitry, for example OFFMUX 20240, for generation and manipulation of AON. OFFSET, and LENfaiH 
fields of logical descriptors and AON pointers. OFFP 20218 may also generate and manipulate for, 
for example, NC 10226, ATU 10228, PC 10234, AOT 10712, MKT 10716. M'^J^^-'B. and o*er d^and 
address structures residing in MEM 1011Z LENP 20220 includes a vertical sMtion Gro= jroM. LENGRF 
20m for storing length fields of logical descriptors, and for storing data. LENP 20220 further ^ludes 
BIAS 20246, used in conjunction vwth LENGRF 20236 and LENALU 20252, for providing tength fields Of 
logical descriptors for MEM 10112 read operations and in particular autoipat'l^'iv PS™r"l"S ftnng 
Sers. AONP 20216 similarty includes a vertical section of GRF 10354, AONGRF 20m A primary 
fijncfion AONGRF 20232 is storing and providing AON fields of AON pointers and logical descriptors. 

Having described structure and operation of DESP 20210, structure and operation of Memory Interface 
<MEMINT) 20212 will be described next below. 

2. Memory Interface 20212 (Rgs. 106, 240) .u ^ u n/icRiiikrT -jaoio 

MEMINT 20212 comrises FU 10120-s interface to MEM 10112. As described above, MEMII^ 20212 
includes Name Cache (NC) 10226, Address Translation Unit (ATU) 10228. and Protection Caf he (PC) l Om 
all of which have been previously briefly described. MEMINT 20212further includes Descnptor Trap (DEST) 
202S6and Data Trap (DAT) 20258. Functions performed by MEMINT 20212 includes (1) resolution of Names 
to logical descriptore. by NC 10226; (2) translation of logical descriptors to physical descriptors, by ATU 
10228; and (3) confirmation of access writes to objects, by PC 10234. _ 

a; shown in Fig. 202, NC 10226 adresa Input (ADR) is connected ^^^^^ 
Write Length Field Input (WU is connected from LENGRF 20236's output NC 1(^'s Wnte Wfset Reld 
Input (WO) and Write AON Reld Input (WA) are connected, fespwAvely. from OFFSCT Bus 2M^^ 
Bus 20230. NC 10226 Read AON ReW (RA). Read Offset Field (RO), and Read Length Field (RL) outputs are 
connected, respectively, to AON Bus 20230, OFFSET Bus 20228. and LENGTH Bus 20226 

DEST 20256-8 biKlirectional AON (AON). Offset (OFF), and Ungth ^^^"^^'t^^'^^^^^^^- 
dir^ctional buses xo and from, respecttvely, AON Bus 20230, OFFSET Bus 20m and "fNGTH Bus 20^6 
■> PC 10234 has AON (AON) and Offset (OFF) inputs connected from, respectively, AON Bus 20230 ana 
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OFf=SET Bus 20228. PC 1 0234 has a Write Entry (WEN) Input connected fronri JPD Bus 1 0142. ATU 10228 has 
AON (AON), Offset (OFF), and Length (LEN) inputs connected from, respectively, AON Bus 20230, OFFSET 
Bus 20228, and LENGTH Bus 20226. ATU 10228's output is connected to physical Descriptor (PD) Bus 
10146, 

^ Rnally, DAT 20258 has a bi-directional port connected to and from JPD Bus 10142. 

a.a. Description Trap 20256 and Data Trap 20258 
Referring first to DST 20256 and DAT 20258, DST 20256 is a register for receding and capturing logical 
descriptors appearing on AON Bus 20230, OFFSET Bus 20228, and Length Bus 20226. SInnllarty, DAT 20258 
is a register for recmving and capturing data words appearing on JPD Bus 10142. DST 20256 and DAT 20258 
may subsequently return captured logical descriptors or data words to, respectively, AON Bus 20230, 
OFFSET Bus 20228, and LENGTH Bus 20226, and to JPD Bus 1D142. 

As previously described, many CS 1 01 10 operations. In particular MEM 101 12 and JP 1 01 14 operations, 
are pipelined. That is. operations are overtapped with certain sets within two or more operations being 
executed concurrently. For example, FU 10120 may submit read request to MEM 10112 and, while MEM 
10112 is accepting and servicing that request, submit a second read request. DEST 20256 and DAT 20258 
assist in execution of overplapping operations by providing a temporary record of these operations. For 
example, a part of a read or write request to MEM 101 1 2 by FU 10120 is a logical descriptor provided to ATU 
10228. If, for example the first red request just referred to results in a ATU 10228 cache miss or a protection 

^0 violation, the logical descriptor of that first request must be recovered for subsequent action by CS 10110 
as previously described. That logical descriptor will have been captured and stored in DEST 20256 and thus 
Is immediately available, so tiiat DESP 20210 is not requited to regenerate that descriptor. DAT 20258 
serves a similar purpose with regard to data being written into MEM 10112 from JP 10114, That is, DAT 
20258 receives and captures a copy of each 32 bit word transferred onto JPD Bus 10142 by JP 101 14w in 

25 event of MEM 101 12 being unable to accept a write request, that data may be subsequently reprovided 
from DAT 20258. 



b.b. Name Cache 10226, Address Translation Unit 10228, and Protection Cache 10234 (Rg. 106) 
Referring to NC 10226, ATU 10228, and PC 1 0234, the^ elements of MEMINT 20212 are primarily cache 

so mechanisms to enhance the speed of FU 10120's interface to MEM 10112, and consequentiy of CS 101 10's 
operation. As described previously, NC 10226 contains a set of logical descriptors corresponding to certain 
operand names currentiy appearing in a process being executed by CS 10110. NC 10226 thus effectively 
provides high speed resolution of certain operand names to corr^ponding logical descriptors. As 
described above with reference to string transfers, NC 10226 will generally contain logical descriptors only 

35 for data items of less than 2!^ bits length. NC 10226 read and write addresses are names provided on 
NAME Bus 20224. Name read and write addresses nr^y be provided from DESP 20210, and in particular 
from OFR* 20218 as previoudy described, or from FUCTL 20214 as will be described in a following 
description of FUCTL 20214. Logical descriptors comprising NC 10226 entries, each entry comprising an 
AON field, an Offset field, a Length field, are written into NC 10226 through NC 10226 inputs WA, WO, and 

40 WL from, respectively, AON Bus 20230, OFFSET Bus 20228, and LENGRF 20236's output Logical 
descriptors read from NC 10226 in response to names provided to NC 10226 ADR input are provided to 
AON Bus 20230, OFFSET Bus 20228, and LENGTH Bus 20226 from, re^>ectively, NC 10226 outputs RA. RO, 
and RL 

ATU 10228 is similarty a cache mechanism for providing high speed translation of logical to physical 

45 descriptors. In general, ATU 10228 will contain, at any given time, a set of logical to physical page number 
mappings for MEM 10112 read and write requests which are currentiy being made, or anticipated to be 
made, to MEM 10112 by JP 10114. As previously described, each physical descriptor is comprised of a 
Frame Number (FN} field, and Offset Within Frame (O) fields, and a Length field. As discussed with 
reference to string transfers, a physical descriptor length field, as in a logical descriptor length field, specify 

so a data item of less than or equal to 32 bits length. Referring to Rg. 106C, as previously discussed a logical 
descriptor comprised of a 14 bit AON field, a 32 bit Offeet field, and Length field, wherein 32 bit logical 
descriptor Offset field is divided into a 1 8 bit Page Number (P) field and a 14 bit Offset within Page (O) field. 
In translating a logici into a physical descriptor, logical descriptor Length and O fields are used directly, as 
respectively, physical descriptor length and 0 fields. Logical descriptor AON and P fields are translated into 

ss physical descriptor FN field. Because no actual translation Is required, ATU 10228 may provide logical 
descriptor L field and corresponding 0 field directly, that is without delay, to MEM 101 12 as corresponding 
physical descriptor 0 and Length fields. ATU 10228 cache entries are thereby comprised of physical 
descriptor FN fields corresponding to AON and P fields of those logical descriptors for which ATU 10228 
has corresponding entries. Because physical descriptor FN fields are provided from ATU 10228's cache, 

fiD rather than directiy as in physical descriptor 0 and Length fields, a physical descriptor's FN field will be 
provided to MEM 10112, for example, one clock cyde later than that physical descriptors O and Length 
{fields, as has been pre^ously discussed. 

Referring to Rg« 202, physical descriptor FN fields to be written into ATU 10228 are, in general, 
generated by DESP 20210. FN fields to be written into ATU 10228 are provided to ATU 10228 Data Input {D\) 

es through JPD Bus 1 01 42. ATU 1 0228 read and write addresses are comprised of AON and P fields of loaicai 
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descriptors and are provided to ATU 10228*8 AON and OFF inputs from, respectively, AON Bus 20230 and 
OFPSET Bus 2022a ATU 10228 read and write addresses may be provided from DESP 20210 or, as 
described further below, from FUCTL 20214. ATU 10228 FN outputs, together with O and Length fields 
comprising a physical descriptor, are provided to PD Bus 10146. 

5 PC 10234 is a cache mechanism for confirming active procedure's access rights to objects identified by 
logical descrfptors generated as a part of JP 10114 read or write requests to MEM 10112. As previously 
described access rights to objects are arbitrated on the basis of subjects. A subject has been defined as a 
particular combination of a principal, process, and domain. A principal, process, and domain are each 
identified by corresponding UlDs. Each subject having access rights to an object is assigned an Active 

10 Subject Number (ASN) as described in a previous description of CS 10110's Protection Mechanism. The 
ASN of a subject currently a<^ve in CS 101 10 Is stored in ASN Register 1 091 6 in FU 1 01 20. Access rights of a 
currently active subject to currently active objects are read from those objects Access Control Lists (ACL) 
10918 and stored in PC 10234. If the current ASN changes, PC 10234 is flushed of corresponding access 
right entries and new entries, corresponding to the new ASN, are written into PC 10234. The access rights 

IS of a particular current ASN to a particular object may be determined by indexing, or addressing, PC 1 0234 
with the AON identifying that object. Addresses to write entries into or read entries from PC 10234 are 
provided to PC 1 0234 AON input from AON Bus 20230. Entries to be written into PC 10234 are provided to 
PC 10234's WEN inputfrom JPD Bus 10142. PC 10234 is also provided with Inputs, not shown in Fig. 202 for 
purposes of clarity, from FUCTL 20214 Indicating the current operation to be perfomed by JP 10114 with 
. 20 respect to an object being presentiy addressed by FU 10120, Whenever FU 10120 submits a read or write 
request concerning a particular object to MEM 101 1 2, AON field of that request Is provided as an addess to 
PC 10234, Access rights of the current active subject to that object are read from corresponding PC 10234 
entry and compared to FUCTL 20214 inputs indicating the particular operation to be performed by JP 10114 
with respect to that object The operation to be performed by JP 10114 is then compared to that active 

25 subject's access rights to that object and PC 1 0234 provides a n output i ndi eating whether that active subject 
possesses the rights required to perform the Intended operation. Indexing of PC 10234 and comparison of 
access rights to intended operation is performed concurrently with translation of the memory request 
logical descriptor to a corresponding physical descriptor by ATU 10228. If PC 10234 indicates that that 
active subject has the required access rights, the intended operation is executed by JP 10114. If PC 10234 

30 indicates that that active subject does not have the required access rights, PC 10234 indicates that a 
protection mechanism violation has occurred and Interrupts execution of the intended operation. 

c-c Structure and Operation of a Generalized Cache and NC 10226 (Rg. 240) 
Ha>nng described overall structure and operation of NC 10226, ATU 10228, and PC 10234, structure and 
3S operation of these caches will be described in further detail below. Structure and operation of NC 10226, 
ATU 10228, and PC 10234 are similar, except that NC 10226 is a four-way set associative cache, ATU 10228 
is a threeway set associative cache and PC 10234 is a two-way set associative cache. 

As such, the stnjcture and operation of NC 10226, ATU 10228, and PC 10234 will be described by 
reference to and description of a generalized cache similar but not necessarily identical to each of NC 
40 10226, ATU 10228, and PC 10234. Reference will be made to NC 10226 in the description of a generalized 
cache next below, both to further illustrate structure and operation of the generalized cache, and to 
describe differences between the generalized cache and NC 10226, ATU 10228 and PC 10234 will then be 
described by description of differences between ATU 10228 and PC 10234 and the generalized cache. 
Referring to Rg. 240, a partial block diagram of a generalized four-way, set associative cache is shown, 
45 Tag Store (TS) 24010 is comprised of Tag Store A (TSA) 24012, Tag Store 8 (TSB) 24014, Tag Store C (TSC) 
24016. and Tag Store D (TSD) 24018. Each of the cache's sets, represented by TSA 24012 to TSD 24018, may 
contain, for example as in NC 10226, up to 16 entries, so that TSA 24012 to TSD 24018 are each 16 words 
long. 

Address inputs to a cache are divided Into a tag field and an index field. Tag fields are stored in die 
so cache's tag store and indexed, that is addressed to be read or written from or to tag store by index field of 
the address. A tag read from tag store in response to index field of an address is then compared to tag field 
of that address to indicate whether the cache contains an entry corresponding to that address, that is, 
whether a cache hit occurs. In, for example, NC 10226, a Name syllable may be comprised of an 8, 12, or 16 
bit binary word, as previously described. The four least significant bits of these words, or Names, comprise 
55 NC 10226's index field while the remaining 4, 8, or 12 most significant bits comprise NC 1 0226's tag field. 
TSA 24012 to TDS 24018 may each, therefore, be 12 entry wide memories to store the 12 bit tag fields of 16 
bit names. Index (INO) or address inputs of TSA 24012 to TSD 24018, would in NC 10226, be connected from 
four least significant bits of NAME Bus 20224 while Tag Inputs (TAGi> of TSA 24012 to TSD 24018 would be 
connected from the 12 most significant bits of NAME Bus 20224. 

As described above, tag outputs of TS 2401 0 are compared to tag fields of addresses presented to the 
cache to determine whether the cache contains an entry corresponding to that address. Using NC 10226 as 
an example 12 bit Tag Outputs (TAGOs) of TSA 24012 to TSD 24018 are connected to first inputs of Tag 
Store Comparators (TSC) 24019, respectively to inputs of Tag Store Comparitor A (TSCA) 24020, Tag Store 
Comparrtor B (TSCB) 24022, Tag Store Comparitor D (TSCD) 24024, and Tag Store Comparitor E (TSCE) 
g5 24026. Second 1 2 bit inputs of TSCA 24020 to TSCE 24026 may be connected from the 12 most significant 
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bits of NAME Bus 20224 to receive tag fields of NC 10226 addresses, TAS 24020 to TSCE 24026 compare tag 
field of an address to tag outputs read from TSA 24012 to TSE 24018 in response to index field of that 
address, and provide four bit outputs indicating which, if any, of the possible 16 entries and their associated 
tag store correspond to that address tag field. TSCA 24020 to TSCE 24026 may be comprised, for example, 
of Fairchild 93846^ 

Four bft outputs of TSCA 24012 to TSCE 24026 are connected in the generalized cache to inputs of Tag 
Store Pipeline Registers (TSPR) 24027; respectively to inputs of Tag Store Pipeline Register A (TSPRA) 
2AG2B, Tag Store Pipeline Register B (TSPRB) 24030, Tag Store Pipeline Register C (TSPRC} 24032, and Tag 
Store Pipeline Register D (TSPRD) 24034. ATU 10228 and PC 10234 is pipelined with a single cache access 
operation being executed in two clock cycles. During first dock cycle tag store is addressed and tags store 
therein compared to tag field of address to provide indication of whether a cache hit has occurred, that is 
whether ca<^e contains an entry corresponding to a particular address. During second dock cyde, as will 
be descnbed below, a detected cache hit is encoded to obtain access to a corresponding entry in cache data 
store. Pipeilne operation over two dock cydes is provided by cache pipeline registers which Include, in 
part TSPRA 24028 to TSPRD 24034. NC 10226 is not pipelined and does not include TSPRA 24028 to TSPRD 

24034. In NC 10226, outputs of TSCA 24012 to TSCD 24024 are connected directly to inputs of TSHEA 24036 
to TSHED 24042, descnbed below. 

Outputs of TSPflA 24028 to TSPRD 24034 are connected to inputs of Tag Store Hit Encoders (TSHE) 

24035, respectively to Tag Store Hit Encoder A {TSHEA} 24036, Tag Store Hit Encoder B (TSHEB) 24038, Tag 
Store Hh Encoder C aSHEC) 24040, and Tag Store Hit Encoder D (TSHED) 24042. I^HEA 24036 to TSHED 
24042 encode, re^iectivety, bit inputs from TSPRA 24028 to TSPRD 24034 to provide single bit outputs 
indicating which, if any, set of the cache's four sets includes an entry corresponding to the address input 

Single bit outputs of TSHEA 24036 to TSHED 24042 are connected to inputs of Hit Encoder (HE) 24044- 
HE 24044 encodes single bit inputs from TSHEA 24(66 to TSHED 24042 to provide two sets of ouputs. Rrst 
outputs cyf HE 24044 are provided to Cache Usage Store (CUS) 24046 and indicate in which of the cache's 
four sets, corresponding to TSA 2401 2 to TSD 2401 8, a cache hit has occurred. As descnbed previously with 
reference to MC 201 16, and will be described further below, CUS 24046 is a memory containing information 
for traddng usage of cache entries. That is, CUS 24046 contains entries indicating whether, for a particular 
Index, Set A, Set B, Set C or Set D of the cache's four sets has been most recently used and which has been 
least recently used. CUS 24046 entries regarding Sets A, B, C. and D are stored in, respecth^ly, memories 
CUSA 24088, CUSB 24090, CUSC 24092, and CUSD 24094. Second output of HE 24044, as described further 
t>elow, is connected to selection input of Data Store Selection Multiplexer (DSSMUX) 24048 to select an 
output from Data Store (DS) 24050 to be provided as output of the cache when a cache hit occurs. 

Referring to DS 24050, as previously described a cache's data store contains the information, or 
entries, stored in that cache. For example, each entry in NC 10226*5 DS is a logical descriptor 

comprised of an AON, and Offset and Length. A cache's data store parallels. In structure and organization, 
that cache's tag store and entries therein are identified and located through that cache's tag store and 
associated tag store comparison and decoding logic. In NC 10226, for example, for each Name having an 
entry in NC 10226 there will be an entry, the tag field of that name, stored in TS 24010 and a corresponding 
entry, a logical descriptor corresponding to that Name, In DS 24050. As described above, NC 10226 is a 
four-way, set assodative cache so that TS 24010 and DS 24050 will each contain four sets of data. Each set 
was previously described as containing up to 16 entries. DS 24050 Is therefore comprised of four 16 word 
memories. Each memory is 65 bits wide, accommodating 28 bits of AON, 32 bits of offset and 5 bits of 
length. These four component data store memories of DS 24050 are indicated in Fig. 240 as Data Store A 
(DSA) 24052, Data Store B (DSB) 24054, Data Store C (DSC) 24056, and Data Store D (DSD) 24058. DSA 
24052, DSB 24(»4, DSC 24056 and DSD 24058 correspond, respectively, in structore, contents, and 
operation to TSA 24012, TSB 24014, TSC 24016 and TSD 24018. 

Data Inputs (DIs) of DSA 24052 to DSD 24058 are, in NC 10226 for example, connected from AON Bus 
20230, OFFSET Bus 20228, LENGTH Bus 20226 and comprise inputs WA, WO, WL respectively of NC 10226. 
DSA 24052 to DSD 24058 DIs are, in NC 10226 as previously described, utilized in writing NC 10226 entries 
Into DSA 24052 to DSD 24058. Address inputs of DSA 24052 to DSD 24058 are connected from address 
outputs of Address Pipeline Register (ADRPR) 24050. As will be described momentarily, except during 
cache flush operations, DSA 24052 to DSD 24058 address inputs are comprised of the same index fields of 
cache addresses as are provided as address inputs to TS 24010, but are delayed by one clock cyde and 
ADRPR 24060 for pipelining purposes. As described above, NC 1 0226 is not pipelined and does not have the 
one dock cyde delay. An address input to the cache will thereby result in corresponding entries, selected 
by index field of that address, being read from TSA 24012 to TSD 24018 and DSA 24052 to DSD 24058. The 
four outputs of DSA 24052 to DSD 24058 selected by a particular index field of a particular address are 
provided as inputs to DSSMUX 24048. DSSMUX 24048 is concurrently provided with selection control 
input from HE 24044. As previously described, this selection input to DSSMUX 24048 is derived from TS 
24010 tag entries and indicates which of DSA 24052 to DSD 24058 entries corresponds to an address 
provided to the cache. In response to that selection comrol input, DSSMUX 24048 selects one of DS 24050's 
four logical descriptor outputs as the cache's output corresponding to that address. DSSMUX 24048's 
output is then provided, through Buffer Driver (BD) 24062 as the cache's output for example in NC 10226 to 
AON Bus 20230, OFFSET Bus 20228, and LENGTH Bus 20226. 
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Referring to ADRMUX 24062, ADRMUX 24062 selects one of two sources to provide address inputs to 
DS 24050 that Is to index to DS 24050. As described above, a first ADRMUX 24082 input Is comprised of the 
cache's address index fields and, for example in NC 10226, Is connected from the four least significant bits 
of NAME Bus 20224. During cache flush operations, DS 24050 address inputs are provided from Flush 
5 Counter (FLUSHCTR) 24066, vtfhich in the example is a four bit counter. During cache flush operations, 
FLUSHCTR 24066 generates sequential bit addresses which are used to sequentially address DSA 24052 to 
DSD 24058. Selection between ADRMUX 24062 first and second inputs, respectively the address index 
fields and from FLUSHCTR 24066, is controlled by Address Multiplexer Select (ADRMUXS) from FUCTL 

20214. , „ , - . 

Validity Store (VALS) 24068 and Dirty Store (DIRTYS) 24070 are memories operating in parallel with, 
and addressed in parallel with TS 24010. VALS 24068 contains entries indicating validity of corresponding 
TS 24010 and DS 24050 entries. That is, VALS 2406B entries indicate v^ether corresponding entries have 
been written into corresponding locations in TS 24010 and DS 24050. In the example, VALS 24068 may 
thereby be a 15 word by 4 bit wide memory. Each bit of a VALS 24068 word indicates validity of a 
corresponding location In ISA 24012 and DSA 24052. TSB 24014 and DSB 24054, TSC 24016 and D^ 
24056, and TSD 24018 and DSD 24058. DIRTYS 24070 similarly Indicates whether corresponding entries in 
corresponding locations of TS 24010 and DS 24050 have been written over, or modified. Again, DIRTYS 
24070 will be a sixteen word by four brt wide memory. 

Address inputs of VALS 24068 and DIRTYS 24070 are, for example in NC 10226, connected from least 
^ significant bits of NAME Bus 20224 and are thus addressed by index fields of NC 10226 addresses in 
parallel with TS 24010. Outputs of VALS 24068 are provided to TSCA 24020 to TSEE 24026 to inhibit outputs 
of TSCA 24020 through TSCE 24026 upon occurrence of an invalid concurrence between a TS 2401 0 entry 
and a NC 10226 address input Similar outputs of DIRTYS 24070 are provided to FUCTL 20214 for use in 
cache flush operations to indicate which NC 10226 entries are dirty and must be written back into an MT 
^ 10^ rather than disgarded. 

Outputs of VALS 24068 and DIRTTS 24070 are also connected, respectiveh^, to Inputs of Validity 
Pipeline Register (VALPR) 24072 and Dirty Pipeline Register (DIRTYPR) 24074. VAIPR 24072 and DIRTYPR 
24074 are pipeline registers similar to TSPRA 24028 to TSPRD 24034 and are provided for timing purposes 
as will be described momentarily. Outputs of VALPR 24072 and DIRTYPR 24074 are connected to inputs of, 
^ respecth^ly. Validity Write Logic (VWL) 24076 and Dlrt:y Write Logic (DWL) 24078. As described above, NC 
10226 is not a pipelined cache and does not include VALPR 24072 and DIRTYPR 24074; outputs of VALS 
24068 and DIRTYS 24070 are connected directly to inputs of VWL 24076 and DWL 24078. Outputs of VWL 
24076 and DWL 24078 are connected, respectively, to data Inputs of VALS 24068 and DIRTYS 24070. Upon 
occurrence of a write operation to TS 24010 and DS 24050, that is writing in or modifying a cache entry, 
^ corresponding validity and dirty word entries are read from VALS 24068 and DIRTYS 24070 by index field of 
tlie caches input addr^. Outputs to VALS 24068 DIRTYS 24070 are received and stored in, respecth^ely, 
VALPR 24070 and DIRTYPR 24074. At start of next clock cycle, validity and dirty words in VALTO 24072 and 
DIRTYPR 24074 are read into, respectively, VWL 24076 and DWL 24078. VWL 24076 and DWL 24078 
respectively modify those validity or dirty word entries from VALS 24068 and DIRTYS 24070 in accordance 
^ to whether the corresponding entries in TS 24010 and DS 24050 are written into or modified. These 
modified validity and dirty words are then written, during second clock cyde, from VWL 24076 and DWL 
24078 into, respectively, VALS 24068 and DIRTYS 24070. Control inputs of VWL 24076 and DWL 24078 are 

^^^^^Relerrin^^ Recent Used Logic (LRUU 24080, LRUL 24080 tracks usage of cache entries. 

^ As previously described, the generalized cache of Rg. 240 is a four way, set associative cache witii, for 
example, up to 16 entries in each of NC 10226's sets. Entries within a particular set are Identified, as 
described above, by indexing the cache's TS 24010 and DS 24050 may contain, concurrently, up to four 
individual entries identified by the same index but distiguished by having different tags. In this case, one 
entry would reside In Set A, comprising TSA 2401 2 and DSA 24052, one in Set B, comprising TSB 24014 and 

so DSB 24054, and so on. Since the possible number of individual entries having a common tag Is greater than 
the number of cache sets, it may be necessary to delete a particular cache entry when another entry having 
the same tag is to be written into the cache. In general, tfie cache's least recently used entry would be 
deleted to provide a location in TS 24010 and DS 24050 for writing in the new entry. LRUL 24080 assists in 
determining which cache entries are to be deleted when necessary in writing in a new entry by tracking and 

55 indicating relative usage of the cache's entries. LRUL 24080 is primarily comprised of a memory, LRU 
Memory (WILRU) 24081, containing a word for each cache set As described above, NC 10226, for example, 
includes 16 sets of 4 frames each, so that LRUL 24080's memory may correspondingly be, for example, 16 
words long. Each word indicates relative usage of the 4 frames In a set and is a 6 bit word. 

Words are generated and written into LRUL 24080's MLRU 24081, through Input Register A, B, C, D 

60 (RABCD) 24083, according to a write only algorithm executed by HE 24044, as described momentarily. Each 
bit of each six word pertains to a pair of frames within a particular cache set and Indicates which of those 
two frames was more recendy used than the ottier. For example. Bit 0 will contain logic 1 if Frame A was 
used more recently than Frame B and a logic zero if Frame B was used more recently than Frame A. 
Similariy, Bit 1 pertains to Frames A and C, Bit 2 to Frames A and D, Bit 3 to Frames B and C, Bit 4 to Frames 

65 B and D, and Bit 5 to Frames C and D. Initially, all bits of a particular LRUL 24080 word are set to zero. 
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Assuming, for example, that the frames of a particular set are used in the sequence Frame A, Frame D. 
Frame B; BHs 0 to 5 of that LRUL 2400) word will initiallv contain all zeros. Upon a reference to Frame A, 
Bits 0, 1, and 2, referring respectively to Frames A and B, Frames A and C, and Frames A and D, will be 
written as logic Vs. Bits 3, 4, and 5, referring respectively to Frames B and C, Frames B an D, and Frames C 

5 and 0, v^rill remain logic 0, Upon reference to Frame D, Bits 0 and 1 , referring respectively to Frames A and B 
and Frames A and C, will remain logic Vs. Bit 2, referring to Frames A and will be changed from logic 1 to 
logic 0 to indicate that Frame D has been referred to more recently than Frame A. Bit 3, referring to Frames 
6 and will remain logic 0. Bits 4 and 5, referring respectively to Frames B and D and Frames C and 0, will 
be written as logic 0, although they are already logic zeros, to indicate respectively that Frame D has been 

to used more recently than Frame B or Frame C. Upon reference to Frame B. Bit 0, referring to Frames A and B, 
will be written to logic 0 to indicate that Frame B has been used more recently than Frame A. Bits 1 and 2, 
referring resectively to Frames A and C and Frames A and will remain respectively as logic 1 and logic 0. 
Bits three and four, referring respecdvely to Frames B and C and Frames B and D, will be written as logics 
Vs to indicate respectively that Frame B has been used more recently than Frame C or Frame D. Bit five will 

fS remain logic 0. 

When it is necessary to replace a cache entry in a particular frame, the LRUL 24080 word referring to. 
the cache set containing that frame will be read from LRUL 24080*$ MLRL 24081 through LRU Register 
(RLRU} 24085 and decoded by LRU Decode Logic (LRUD) 24087 to Indicate which is least recently used 
frame. This decoding is executed by means of a Read Only Memory operating as a set of decoding gating. 
20 Having descril^ed the structure and operation of a generalized cache as shovim in Fig. 240, with 
references to NC 10226 for illustration and to point out differences between the generalized cache and NC 
10226, structure and operation of ATU 10228 and PC 10234 will be described next below. ATU 10228 and PC 
10234 will be described by describing the differences between ATU 10228 and PC 10234 and the 
generalized cache and NC 10226. ATU 10228 will be described first, followed by PC 10234. 

25 

d.d. Address Translation Unit 10228 and Protection Cache 10234 
ATU 10228 is a three-way, set associative cache of 16 sets, that is contains 3 frames for each set 
Structure and operation of ATU 10228 Is similar to the generalized cache described above. Having 3 rather 
than 4 frames per set ATU 10228 does not include a STD 24018, AT5CE 24026, ATSPRD 24034, ATSHED 

30 24042, or ADSO 2405a As previously described ATU 10228 address inputs comprise AON and 0 fields of 
logical descriptors. AON fields are each 28 bits and O fields comprise the 1 8 most significant bi^ of logical 
descriptor offset fields, so that ATU 10228 address inputs are 48 bits wide, four least significant iMts of 0 
fields are used as Index. AON fields and the 14 most ^gniOcant bits of O field comprise ATU 10228's tags. 
ATU 10228 tags are thereby each 42 bits in width. Accordingly, TSA 24012, T5B 24014, and TSC 24016 of 

35 ATU 10228's TS 24010 are each 16 words long by 42 bits wide. 

DSA 24052, DSB 24054, and DSC 24056 of ATU 10228 are each 16 bits long. ATU 10228 outputs are, as 
previously described, physical descriptor Frame Number (FN) fields of 13 bits each. ATU 10228's DSA 
24052. DSB 24054, DSC 24056 are thereby each 13 bits wide. 

ATU 10228's LRUL 24080 is similar in structure and operation to that of the generalized cache. ATU 

40 12028's LRUL 24080 vrards, each corresponding to an ATU 10228 set, are each 3 bits in width as 3 bits are 
sufficient to Indicate relative usage of frames within a 3 frame set In ATU 10228, Bit 1 of an LRUL 24080 
word Indicates whether Frame A was used more recentiy than Frame 6, Bit 2 whether Freme A was used 
more recently than Frame C, and Bit 3 wt^ther Frame B was used more recently than Frame C. In all other 
respects, other ttian as stated above* ATU 10228 is amiiar in structure and operation to the generalized 

^ cache. 

Referring to PC 1 0234, PC 10234 is a two-way, set associative cache of 8 sets, that is has two frames per 
set. Having 2 rather than 4 frames, PC 10234 will not include a TSC 24016, a TSD 24018, a TSCC 24024 a 
TSCD 24026, a TSPRC 24032, a TSPRD 24034, a TSHEC 24040, a TSHED 24042, a DSC 24056, or a DSD 
24058. 

gg Address inputs of PC 10234 are tiie 28 bit AON fields of logical descriptors. The 3 least significant bits of 
those AON fields are utilized as indexes for addressing PC 10234's TS 24010 and DS 24050. The 25 most 
significant bits of those AON field address inputs are utilized as PC 10234's tags, so that PC 10234's TSA 
24012 and TSB 24014 are each 8 word by 25 bit memories. 

Referring to PC 10234's LRUL 24080, a single bit is sufficient to indicate which of the two frames in each 

^ of PC 10234's sets was most recently accessed. PC 10234's LRUL 24080's memory is thereby 8 vrords, or 
sets long, one bit wide. 

As previously described, PC 10234 entries comprise information regarding access rights of certain 
active subjects to certain active objects. Each PC 10234 entry contains 35 bits of Information. Three bits of 
this information indicate whether a particular subject was read, write, or execute rights relative to a 
so particular object The remaining 32 bits effectively comprise a length field Indicating the volume or portion, 
that is the number of data bits, of that ob]ect to which those access rights pertain. 

Referring again to Fig. 240, PC 10234 differs from the generalized cache and from NC 10226 and ATU 
10228 in further including Extent Check Logic <EXTCHK) 24082 and Operation Check Logic (OPRCHK) 24084. 
PC 10234 entries include, as described above, 3 bits identifying type of access rights a particular subject has 
es to a particular object These 3 bits, representing a Read (R), Write (W), or Execute (E) right, are provided to a. 
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first input of OPRCHK 24084. Aaecond Input of OPRCHK 24084 is provided from FUCTL 20214 and specifies 
whether JP 1011 4 intends to perform a Read <RI), a Write (Wl), or Execute (El), operation with respect to that 
object OPRCHK 24084 compares OPRCHK 24084 access right inputs from DS 24050 to OPRCHK 24084's 
Intended operation input from FUCTL 20214. If that subject does not possess the rights to that object which 

s are required to perform the operation intended by JP 10114, OPRCHK 24084 generates an Operation 
Violation (OPRV) Indicating that a protection violation has occurred. 

Similarly, the 32 bits of a PC 10234 entry regarding extent rights is provided as an input (EXTENT) to 
EXTCHK 24082, As stated above, EXTENT field of PC 10234 entry indicates the length or number of data 
bits, within an obect, to which those access rights pertain. EXTENT field from PC 10234 entry is compared, 
by EXTCHK 24082, to Offset field of the logical descHptor of the current JP 101 14 request to MEM 10112 for 
which a current protection mechanism check is being made. If comparison of extent rights and offset field 
indicate that the current memofY request goes beyond the object length to which the corresponding rights 
read from DS 24050 apply, EXTCHK 24082 generates an Extent Violation (EXTV) output EXTV indicates that 
a current memory request by JP 101U refers to a portion of an ob\ecX to which the PC 10234 entry read 

'5 from BS 24050 does not apply. As described previously, each read from or vim'te to MEM 10112, even as 
part of a string transfer, is a 32 bit word. As such, EXTCHK 24082 will generate an EXTV output when 
OFFSET field of a current logical descriptor describes a segment of an object less than 32 bits from the limit 
defined by EXTENT field of the PC 10234 entry provided in response to that logical descriptor. EXTV and 
OPRV are gated together, by Protection Violation Gate (PVG) 24086 to generate Protection Violation 

20 (PROTV) output indicating that either an extent or an operation violation has occurred. 

Having described the structure and operation of MEMINT 20212, and previously the structure and 
operation of DESP 20210, structure and operation of FUCTL 20214 will be described next below. 

3. Fetch Unit Control Logic 20214 (Rg. 202) 

25 The following descriptions will provide a detailed description of FU 1O120's structure and operation. 
Overall operation of FU 10120 will be described first, followed by description of FU 101 20's structure, and 
finally by a detailed description of FU 10120 operation. 

As previously descnbed, FUCTL 20214 directs operation of JP 10114 in executing procedures of user's 
processes. Among the functions perfomied by FUCTL 20214 are, first, maintenance and operation of CS 

30 10110*8 Name Space, UID, and AON based addressing system, previously described; second. 
Interpretation of SOPs of user's processes to provide corresponding sequences of microinstructions to FU 
10120 and EU 10122 to control operation of JP 10114 in execution of user's processes, previously 
described; and, third, control of operation of CS 10110's intemal mechanisms^, for example CS 10110*3 
stack mec^ianisms, ^ 

35 As will be described in further detail below, FUCTL 20214 Includes prefetcher (PREF) 20260 which 
generates a sequence of logical- addresses, each logical address comprising an AON and an offset field, for 
riding S4nstTuctions (SINs) of a user's program from MEM 101 12. As previously described, each SIN may 
be comprised of an S-Operation (SOP) and one or more operand Names and may occupy one or more 32 
bit words. SINs are read from MEM 101 12 as a sequence of single 32 bit words, so that PREF 20260 need not 

^ specify a length field in a MEM 10112 read request for an SIN. SINs are read from MEM 101 12 through MOD 
Bus 10144 and are captured and stored in Instruction Buffer (INSTB) 20262. PARSER 20264 extracts, or 
parses, SOPs and operand Names from INSTB 20262;PARSER 20264 provides operand Names to NC 10226 
and SOPs to FUS Intrepreter Dispatch Table (FUSDT) 11010 and to EU Dispatch Table (EUSDT) 20266 
through Op-Code Register (OPCODEREQ) 20268. Operation of INSTB 20262 and PARSER 20264 Is 

45 Domnalled by Cun^ent program Counter (CPC) 20270, initial Program Counter (IPC) 20272. and Executed 
program Counter {EPC) 20274. 

As previously described, FUSDT 11010 provides, for each SOP received from OPCODEREG 202^, a 
corresponding S-lnterpreter Dispatch (SO) Pointer, or address, to FUSITT 11012 to select a corresponding 
sequence of microinstructions to direct operation of JP 10114, in particular FU 10120, As previously 

so described, FUSITT 11012 also contains sequences of microinstructions for controlling and directing 
operation of CS 10110*5 intemal mechanisms, for example those mechanisms such as RCWS 10358 which 
are involved in swapping of processes. EUSDT 20266 performs an analogous function with respect to EU 
10122 and provides SD Pointers to EU S-lnterprcter Tables {EUSHTs) residing in EU 1012Z 

Micro-Program Counter (mPC) 20276 provides sequential addresses to FUSITT 11012 to select 

a individual microinstructions of sequences of microinstructions. Branch and Case Logic (BRCASE) 20278 
provides addresses to FUSITT 1 1 01 2 to select mlcroinstmctions sequences for microinstructions branches 
and and cases. Repeat Counter (REPCTR) 20280 and Page Number Register (PNREG) 20282 provide 
addresses to FUSITT 11012 during FUSITT 11012 load operations. 

As previously described, FUSITT 1 1012 is a writable microinstruction control store which is loaded with 

60 selected S-lnterpreters (SINTs) from MEM 10112. 

FUSITT 1 1 01 2 addresses are also provided by Event Logic (EVENT) 20284 and by JAM input from NC 
1022a As will be described further below, EVENT 20284 Is part of FUCTL 20214's circuitry primarily 
concerned with operation of CS 10110's intemal mechanisms. Input JAM from NC 10226 initiates certain 
FUCTL 20214 control functions for CS 10110's Name Space addressing mechanisms, and in particular NC 

65 10226. Selection between the above discussed address inputs to FUSITT 11012 Is controlled by S- 
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Interpreter Table Next Address Generator Logic {SITTNAG) 20286. 

Other portions of FUCTL 20214's circuitry are concerned wmi operation of CS 10110's internal 
mechanisms- For example, FUCTL 20214 Includes Return Control Word Stack (ROWS) 10358, previously 
described with reference to CS 10110's Stack Mechanisms. Register Address Generator <RAG) 20288 
« provides pointere for a<klressing of GRF 10354 and ROWS 10358 and includes Micro-Stack Pointer 
Registers (MISPR) 10356. , ^ , ^^^^^^ 

As previously described, MISPR 10356 mechanism provides pointers for addressing Micro-Stack (MIS) 
10368. As will be described further below, actual MIS 10368 Pointers pointing to current, previous, and 
bottom frames of MIS 10368 reside in Micro-Cdntrol Word Register 1 (MCW1) 20290. MCW1 20290 and 
^0 Micro-Control Word Zero Register <MCWO) 20292 together contain certain information indicating the 
current execution environment of a microinstruction sequence currently being executed by FU 10120. This 
execution information is used in aide of execution of these microinstruction sequences. State Registers 
(STATE) 20294 capture and store certain information regarding State of operation of FU 10120. As 
described further below, this information, referred to as state vectors, is used to enable and direct 
operation of FU 10120. 

Timers (TIMERS) 20296 monitor elapsed time since occurrence of the events requiring servicing by FU 
1 0120. If waiting time for these events exceeds certain limits, TIMERS 20296 indicate that these limits have 
been exceeded so that service of those events may be initiated. 

Finally, Fetch Unit to E Unit Interface Logic (FUEUINT) 20298 comprises the FU 10120 portion of the 
^ interface between FU 10120 an EU 10122. FUEUINT 20298 is primary path through which operation of FU 
10120 and EU 10122 is coonjinated. 

Having described overall operation of FU 10120, structure of FU 10120 will be described next below 
with aide of Fig, 202, description of FU 10120*8 structure will be followed fay a detailed description of FU 
10120 wvherein further, more detailed, diagrams of certain portions of FU 10120 will be introduced as 
^ required to enhance darfty of presentation. 

a.a. Fetch Unit Control Logic 20214 Overall Structure 
Referring again to Rg. 202, as previously described Fig. 202 includes a partial block diagram of FUCTL 
20214, Following the same sequence of description as above. PREF 20260 has a 28 bit bi^iirectional port 
so connected to AON Bus 20230 and 32 bit bi-directional port directed from OFFSET Bus 2022a A control input 
of PREF 20260 Is connected from control output of INSTB 20262, 

INSTB 20262 32 bit data input (Dl) is connected from MOD Bus 10144. INSTB 20262's 16 bit output (DO) 
is connected to 16 bit bhdi^onal input of OPCODEREG 20268 and to 16 bit NAME Bus 20224. 
OPCODEREG 20268*5 Input comprises 8 bits of SINT and 3 bits of dialect selection. As previously described^ 
35 NAME Bus 20224 is connected to 16 bit bi-directional port of Name Trap (NT) 20254, to address input ADR 
of NC 10226, and to inputs and outputs of OFFP 20228, Control inputs of INSTB 20262 and PARSER 20264 
are connected from a control output of CPC 20270. 

Thirty-two bit input of CPC 20270 is connected from JPD Bus 10142 and CPC 2O270's 32 bit output is 
connected to 32 bit input of IPC 20272. Thirty-two twt output of IPC 20272 is connected to 32 krit input of EPC 
40 20274 and to JPD Bus 10142. EPC 20274's 32 bit output Is similarly connected to JPD Bus 10142. 

Eleven bit outputs of OPCODEREG 20268 are connected to 1 1 bit address inputs of FUSDT 11010 and 
EUSDT 20266. These 11 bit address inputs to FUSDT 11010 and EUSDT 20266 each comprise 3 bits of 
dialect selection code and 8 bits of SINT code. Twelve bit SOT outputs of EUSDT 20266 is connected to 
inputs of Microinstru<^on Control Store in EU 10122, as will be described in a following description of EU 
4S 10122. FUSDT 1 1 01 0 has, as described further below, two outputs connected to address (ADR) Bus 20298. 
First output of FUSDT 1 1010 are sbc bit SDT pointers, or addresses, corresponding to generic SINTs as will 
be described further below. Second output of FUSDT 11010 are 16 bit SDT pointers, or addresses, for 
algoritiim microinstruction sequences, again as will be described further befow, 

Refening to RCWS 10358. RCWS 10358 has a first bidirectional port connected from JPD Bus 10142. 
so Second, third, and fourth bi-directional ports of RCWS 10358 are connected from, respectively, a bi- 
directional port of MCW1 20290, a first bi^firectional port EVENT 20284, and a t>i-directional port of mPC 
20276. An output of RCWS 10358 is connected to ADR Bus 20298. 

An input of mPC 20276 is connected from ADR Bus 20298 and first and second outputs of mPC 20276 
are connected Xo, respectively, an input of BRCASE 20278 and to ADR Bus 20298. An output of BRCASE 
ss 20278 is connected to ADR Bus 20298. 

As descnlied above, a first bi-directional port of EV^NT 20284 Is connected to RCWS 10358. A second 
bidirectional port of EVENT 20284 is connected from MCWO 20292. An output of EVENT 20284 is connected 
to ADR Bus 20298. 

Inputs of RPCTR 20280 and PNREG 20^ are connected from JPD Bus 10142. Outputs of RPCTR 20280 
60 and PNREG 20282 are connected to ADR Bus 20298. 

ADR Bus 20298, and an input from a first output of FUSOT 1 1012, are connected to inputs of STTTNAG 
20286. 

Output of SITTNAG ^86 is connected, through Control Store Address (CSADR) Bus 20299, to address 
input of FUSITT 11012. Data input of FUSITT 11012 is connected from JPD Bus 10142. Control outputs of 
es FUSnr 1 101 2 are connected to almost all elements of JP 101 14 and thus, for clarity of presentation, are not 
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shown in detail by drawn physical connections but are described In following descriptions. 

As described above, MCWO 20292 and MCWl 20290 have bi-directiona! ports connected to, 
respectively, bidirectional ports of EVENT 20284 and to a second bidirectional port of RCWS 10358. Outputs 
of MCWO 20292 and MCWl 20290 are connected to JPD Bus 10142. Other inputs of MCWO 20292 and 
^* MCWl 20290. as will be described further below, are connected from several other elements of JP 10114 
and, for clarity of presentation, are not shown herein In detail but are described in the following text STATE 
20294 similarly has a large number of inputs and outputs connected from and to other elements of JP 
101 14, and in particular FU 10120. Inputs and outputs of STATE 20294 are not indicated here for clarity of 
presentation and will be described In detail below. 

RAG 20288 has an input connected from JPD Bus 10142 and other inputs connected, for example, from 
MCWl 20290. RAG 20288, including MI5PR 10356, provides outputs, for example, as address Inputs to 
RCWS 10358 and GRF 10354. Again, for darity of presentation, inputs and outputs of RAG 20288 are not 
shown in detail in Fig. 202 but will be described in detail further below. 

TIMERS 20296 receive inputs from EVENT 20284 and FUSITT 11012 and provide outputs to EVENT 
20284. For clarity of presentation, these indications are not shown In detail in Fig. 202 but will be described 
further below* 

FUINT 20298 receives contrd inputs from FUSITT 11012 and EU 10122. FU1NT 20298 provides outputs 
to EU 10122 and to other elements of FUCTL 20214. For darity of presentation, connecticwis to and from 
FUINT 20298 are not shown In detail In Rg. 202 but wilt be described in further detail below. 

^ Having described the overall operation, and structure, of FUCTL 20214, operation of FUCTL 20214 will 
be described next below. During the following descriptions further diagrams of certain portions of FUCTL 
20214 unll be Introduced as required to disclose structure and operation of FUCTL 20214 to one of ordinary 
skill In the art FUCTL 20214's oi^ration with regard to fetching and interpretation of SINs, that is SOPs and 
operand Names, wilt be described first, followed by description of FUCTL 20214's operation with regard to 

^ CS 1 0lio's internal mechanisms. 

b.b. Fetch Unit Control Logic 20214 Operations 
Referring first to those elements of FUCTL 20214 directly concerned with control of JP 10114 in 
response to SOPs and Name syllables, those elements Include: <1) PREF 20260; (2) INSTB 20262; (3) 
30 PARSER 20264; <4) CPC 20270, IPC 20272, and EPC 20274; (5) OPCODEREG 20268; (6) FUSDT 11010 and 
EUSDT20286; (7) mPC 20276; (8) BRCASE 20278; (9) REPCTR 20280 and PNREG 20282; (10) a part of RCWS 
10358; (11) SITTNAG 20^; (12) FUSnT11012; and, (13) NT 20254. These FUCTL 20214 elements will be 
described below in the order named. 

3S a^^. Prefetcher 20260, Instruction Buffer 20262, Parser 20264, Operation Code Register 20268, 

OPC 20270, IPC 20272, and EPC 20274 (Rg, 241) 
As described above, PREF 20260 generates a series of addresses to MEM 101 12 to read SINs of user's 
programs from MEM 10112 to FUCTL 20214, and in particular to INSTB 20^2. Each PREF 20260 read 
request transfers one 32 bit word from MEM 101 1 Z Each SIN may be comprised of an SOP and one or more 

40 Name syllables. Each SOP may comprise, for example, 8 bits of information while each Name syllable may 
comprise, for example, 8, 12, or 16 bits of data. In general, and as will be described In further detail in a 
following description of STATE 20294, PREF 20260 obtains access to MEM 10112 on alternate 110 
nanosecond system clock cycles. PREF 20260's access to MEM 10112 Is conditional upon INSTB 20262 
indicating that INSTB 20262 is ready to receive an SIN read from MEM 10112. In particular, INSTB 20262 

45 generates control output Quiry Prefetch (QPR to PREF 20260 to enable PREF 20260 to submit a request to 
MEM 10112 when, as described further below, INSTB 20262 is ready to receh^e an SIN read from MEM 
10112. 

PREF 20260 is a counter register comprised, for example of SN74Sl63s. 

Bi-directional inputs and outputs of PREF 20260 are connected to AON Bus 20230 and OFFSET Bus 
so 20228. As PREF 20260 reads only single 32 bit words, PREF 20260 is not required to specify a l-ENGTH field 
as part of an SIN read request, that is an AON and an OFFSET field are sufficient to define a single 32 bit 
word. At start of read of a sequence of SINs from MEM 101 12, address (AON and OFFSET fields) of first 32 
bit word of that SIN sequence are provided to MEM 10112 by DESP 20210 and concurrently loaded, from 
AON Bus 20230 and OFFSET Bus 20228, Into PREF 20260. Thereafter, as each successive thirty-two bit word 
ss of the SIN'S sequence Is read from MEM 10112, the address residing in PREF 20260 is Incrememed to 
specify successive 32 bit words of that SIN's sequence. The successive single word addresses are, for all 
words after first word of a sequence, provided to MEM 10112 from PREF 20260. 

As described above, INSTB 20262 receh^es SINs from MEM 10112 through MOD Bus 10144 and, with 
PARSER 20264 and operating under control of CPC 20270, provides Name syllables to NAME Bus 20224 
60 and SINs to OPCODEREG 20268, INSTB 20262 is provided, together with PREF 20260 to increase execution 
speed of SINS. 

Referring to Fig. 241, a more detailed block diagram of INSTB 20262, PARSER 20264, CPC 20270, IPC 
20272« EPC 20274 as shown. INSTB 20262 is shown as comprising two 32 bit registers having parallel 32 bit 
inputs from MOD Bus 10144. INSTB 20262 also receives two Write Ciodc (WC) inputs, one for each 32 bit 
6S register of INSTB 20262, from Instruction Buffer Write Control (INSTBWC) 24110. INSTB 20282's outputs 
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are structured as eight eight bit Basic Syllables (BSs), indicated as BSO to BS7. BSO, BS2, BS4, and BS6 are 
ORed to comprise eight bit Basic Syllable, Even (BSE) of INSTB 20262 while BSO, BS3, BSS, and BS7 are 
similarty ORed to comprise Basic Syllable, Odd (BSO) of INSTB 20262. BSO and BSE are provided as inputs 
of PARSER 20264, 

^ • PARSER 20264 receives a first control input from Current Syllable Size Register (CSSR) 24112, 
associated with CPC 20270. A second control input of PARSER 20264 is provided from Instruction Buffer 
Syllable Decode Register (IBSDECR) 24114, also associated wth CPC 20270. PARSER 20264 provides an 
eight bit output to NAME Bus 20224 and to input of OPCODEREG 20268. 

Referring to INSTBWC 24110, INSTBWC 24110 provides, as described further below, control signals 
pertaining to writing of SINs Into INSTB 20262 from MOD Bus 10144. INSTBWC 24110 also provides control 
signals pertaining to operation of PREF 20260. In addition to WC outputs to INSTB 20262, INSTBWC 241 1 0 
provides control output QPF to PREF 20260, control output Instruction Buffer Hung (IBHUNG) to EVENT 
20284, and control signal Instruction Buffer Walt (IBWAIT) to STATE 20294. INSTBWC 24110 also receives a 
control input BRANCH from BRCASE 20278 and an error input from TIMERS 20296. 

Referring to CPC 20270, IPC 20272, and EPC 20274, IPC 20272 and EPC 20274 are represented in Rg. 241 
as in Fig. 202. Further FUCTL 20214 circuitry is shown as associated with CPC 20270. CPC 20270 is a twenty- 
nine bit register receh/ing bits one to twety-five (CPC( 1 — ^25)) from bits one to twenty-five of JPD Bus 10142. 
CPC 20270 Bit 0 (CPCO) is provided from CPCO CPCO Select (CPCOS) 241 16. Inputs of CPCOS 241 16 are Bit 
1 output from CPC 20270 (CPCI) and Bit 0 from JPD Bus 10142. Bits twentysix, twenty-seven, and twenty- 

20 eight of CPC 20270 (CPC(2628)) are provided from CPC Muttiplexer (CPCMUX) 2411&. CPCMUX 241 18 also 
provides an input to IBSDECR 241 14. Inputs of CPCMUX 24118 are bits twenty-five, twenty-six, and twenty- 
eight from JPD Bus 10142 and a three bit output of CPC Arithmetic and Logic Unit (CPCALU) 24120. A first . 
input of CPQVLU 24T20 Is connected from output bits 26. 27, and 28 of CPC 20270. Second input of CPCALU 
24120 is connected from CSSR 24112, CSSR 24112's input is connected from JPD Bus 10142. 

2^ As described above, INSTB 20262 is implemented as a sbcty-lbur bit wide register. INSTB ^62 Is 

organized as two thirty^cwo bit words, referred to as instruction Buffer Word 0 (ISO) and Instruction BufTiBr 
Word 1 (IB1), and operates as a two word, first-ln-first-out buffer memory. PREF 20260 loads one of IBO or 
IB1 on each memory reference by PREF 20260. Only PREF 20260 may load INSTB 20262, and INSTB 20262 
may be loaded only from MOD Bus 10144. Separate clocks, respecth^ely Instruction Buffer Write Clock 0 

30 (IBWCO) and Instruction Buffer Write Qock 1 (IBWCl), are provided from INSTBWC 24110 to load, 
respectively* IBWD and IBW1 into INSTB 20262. IBWCO and IBWC1 are each a gated 1 10 rrano-second dock. 
An IBWO or an IBW1 Is written into INSTB 20262 when, respectively, IBWCO or IBWC1 is enabled by 
INSTBWC 24110. IBWCO and IBWC1 will be enabled only when MEM 10112 indicates that data for INSTB 
20262 is availabe by asserting interface control agnal DAVI as previoudy discussed. 

3S INSTBWC 241 1 0 is primarily concerned with control of FU 10120 with respect to writing of SINs into 

INSTB 20262. As described above, INSTBWC 241 1 0 provides IBWCO and IBWC1 to INSTB 20262. IBWCO and 
BWC1 are enabled by INSTBWC 24110*5 input DAVI from MEM 10112. Selection between IBWCO and 
IBWC1 is controlled by INSTBWC 24110*5 input from CPC 20270. hi particular, and as will be descrit>ed 
further below, BH 26 (CPC 26) of CPC 20270's twenty-nine bit word indicates whether IBWO or 1SW1 is 

40 written into INSTB 20i262. 

In addition to controlling writing of IBWO and IBW1 into INSTB 20262, INSTBWC 241 10 provides control 
si gnals to elements of FU 10120 to control reading of SINs from MEM 101 12 to INSTB 20262. In this regard, 
INSTBWC 24110 detects certain conditions regarding status of SIN words in INSTB 20262 and provides 
corresponding control signals, described momentarily, to other elements of FU 10120 so that INSTB 20262 
45 would generally a^vays contain at least one valid SOP or Name syllable. First, if INSTB 20262 is not full, that 
is either IBWO or IBW1 or both is invalid, for example because IBWO has been read from INSTB 20262 and 
executed, INSTBWC 241 10 detects this condition and provides control signal QPF to PREF 20262 to inrtiate a 
read from MEM 10112. INSTBWC 24110 currently enables either IBWO or IBW1 portion of INSTB 20262 to 
receive the word read from MEM 10112 in response to PREF 20260's request As stated above, this 
60 operation will be initiated when INSTBWC 24110 detects and indicates, by generating a validity flag, that 
either IBWO or IBW1 is invalid. In this case, IBWO or IBW1 w\{\ be indicated as invalid when read from INSTB 
20262 by PARSER 20264. As will be described further below, INSTBWC 24110 validity flags for IBWO and 
IBW1 are generated by INSTBWC 24110 control inputs comprising Bits 26 to 28 (CPC 26—28) from CPC 
20270 and by current syllable size or value, flag (K) input from CSSR 241 12. Secondly, INSTBWC 241 10 will 
ss detect when INSTB 20262 is empty, that is when both IBWO and 1BW1 are invalid, as just described, or when 
only a half of a sbcteen bit Name syllable is present in INSTB 20262. In response to either condition, 
INSTBWC 241 10 will generate control signal IBWAIT to STATE 20294. As v«ll be described further below, 
IBWAIT will reailt In suspension of execution of microinstructions referencing INSTB 20262. PREF 20260 
requests to MEM 10112 will already have t^een initiated, as described above unless certain other corditions, 
eo described momenterily, occur. Thirdly, INSTBWC 241 10 will detect when INSTB 20262 is empty and PREF 
20262 is hung, that is unable to submit requests to MEM 10112, and a current microinstruction is 
attempting to parse a syllable from INSTB 20262. In this case, INSTBWC 241 10 will generate control signal 
Instruction Buffer Hung (IBHUNG) to B/EHT 20284. As will be described further below, IBHUNG will result 
In initiation of a microinstruction sequence to restore flow of words to INSTB 20262. Fourthly, INSTBWC 
65 24110 will detect, through microinstruction control signals provided from FUSITT 11012, when a branch In 
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a microinstruction sequence provided by FUSiTT 11012 in response to an SOP occurs. In this case, both 
IBWO and IBW1 will be flaged as invalid. INSTBWC 241 10 will then ignore SIN words being read from MEM 
10112 in response to a previously submitted PREF 20260 request but not yet received at the time the 
branch occurs. This prevents INSTB 20260 from receiving invalid SIN words; PREF 20260 and INSTB 20262 
^ will then proceed to request and receive valid SIN words of the branch. 

As described above, PARSER 20264, operating under control of CPC 20270 and CPC 20270 associated 
circuitry, reads Name syllables and SOPs from INSTB 20262 to, respectively, NAME Bus 20224 and 
OPCODEREG 20^8. PARSER 20264 operates as a multiplexer with associated control logic 

As previously described, INSTB 20262 is intemally structured as eight, eight bit words, BSO to BS7. 
IBWO compnses BSO to B3 while IBW1 comprises BS4 to BS7. Each SOP is comprised of eight bits of data 
and thus comprises one Basic Syllable while each Name syllable comprises 8, 12, or 16 bits of data and thus 
. comprises either one or two Basic Syllables. Name syllable size, as previously stated. Is indicated by 
Cunrent Syllable Size Value K stored in CSSR 24112. 

BSO and BS4 are loaded into INSTB 20262 from MOD Bus 10144 bits zero to seven while BS2 and BS6 
- are loaded from MOD Bus 10144 bits sixteen to twenty-three. BS1 and BS5 are loaded from MOD Bus 10144 
bits eight to fifteen while BS3 and BS7 are loaded from MOD Bus 10144 bits twenty-four to thirty-one. Odd 
numbered Basic Syllable outputs BS1, BS3, BS5, and BS7 are ORed to comprise eight bit Basic Syllable, 
Odd output BSO of INSTB 2026^ Even numbered Basic Syllable outputs BSo, BS2, BS4 and BS6 of INSTB 
20262 are similarly ORed to com|Mise eight bit Basic Syllable, Even output BSE. At any time, one odd 

^ numbered Basic Syllable output and one even numbered Basic Syllable output of INSTB 20262 are selected 
as inputs to PARSER 20264 by Instruction Buffer Read Enable (IBORE) enable and selection signals 
provided to INSTB 20262 by I6SDECR 24114. IBSDECR 24 114 includes decoding circuitry, input to IBSDECR 
24114's decoding logic is comprised of three bits (RCPC(26— 28)) provided from CPCMUX 24118. As 
indicated in Rg. 241, CPC (26—28) may be provided from JPD Bus 10142 bits 25 to 28 or from output of 

^5 CPCALU 24120. One input CPCALU 241 20 Is CPC (26—28) from CPC 20270. Operation of CPC 20270 and CPC 
20270*8 associated circuitry will be described further below. RCPC (26—28) is decoded by IBSDECR 241 14 
to gmerate IBORE (0—7) to INSTB 20262. RCPC 26 and RCPC 27 are decoded to select one of the four odd 
numbered Basic Syllable outputs (that is BS1 , BS3, BS5 or BS7} of INSTB 20262 as the odd numbered basic 
syllable input to PARSER 20264. RCPC 28 selects either the preceding or the following even numbered 

^ Basic Syllable output of INSTB 20262 as the even numbered Basic Syllable input to PARSER 20284. The 
eight decoded bits of IBORE (0—7) generate by IBDECR 24114 decoding logic are loaded into IBSDECR 
24114 eight bit register and subsequently provided to INSTB 20262 as IBORE (0—7). 

PAR^ 20264 selects BSO, or BSE, or both BSO and BSE, as PARSER 20264s output to NAME Bus 
20224 or to OPCOKREG 20268. In the case of an SOP or an eight bit Name syllable, either BSO or BSE will 

^ be selected as PARSER 20264's output In the case of a twehre or sixteen bit Name syllable, both BSO and 
BSE may be selected as PARSER 20264's output PARSER 20264 operation is controlled by microinstruction 
control outputs from FUSITT 11012. 

Program counters IPC 20272, EPC 20274, and CPC 20270 are associated v«th control of fetching and 
pareing of SINs. In general, IPC 20272, EPC 20274, and CPC 20270 operate under microinstruction control 

^ from FUSITT 11012. 

CPC 20270 Is Current Program Counter and contains 28 bits pointing to the current syllable in 1NST6 
20272. Bits 29 to 31 of CPC 20270 are not provided, so the bits 29 to 31 of CPC 20270's output are zero, which 
guarantees byte boundaries for SOPs. (intents of CPC 20270 are thereby also a pointer which is a byte 
align offset into a current procedure object Initial Program Counter {IPC^ 20272 is a btjffer register 
^ connected from output of CPC 20270 and provided for timing overiap. IPC 20272 may be loaded only from 
CPC 20270 which, as previously described. Is 29 bits wide, that does not contain bits 29, 30, and 31 which 
are forced to zero in IPC 20272. IPC 2(X272 may be read onto JPD Bus 10142 as a start value in an 
unconditfonal branch. 

EPC 20274 is a thirty-two bit register usually containing a pointer to the current SOP being executed. 
SO Upon occurrence of an SOP branch, the pointer in EPC 20274 will point to the SOP from which the branch 
was executed. The pointer residing in EPC 20274 is an offset into a cunrent procedure object. EPC 20274 
may be loaded only from IPC 20272, and may be read onto JPD Bus 10142. 

Referring again to CPC 20270, as described above CPC 20270 is a current syllable counter. CPC 20270 
contains a pointerto the next SOP syllable, or Base Syllable, to be parsed by PARSER 20264. As SOPs are 
ss always on byte boundaries, CPC 20270 pointer is 29 bits wide, CPC (0—28). The three low order bits of CPC 
20270*8 pointer, that is CPC (29—31). do not physically exist and are assumed to be always zero. CPC 
20270's pointer to next instruction syllable to be parsed thereby always points to byte boundaries. 

CPC 20270 bits 26 to 28, CPC (26—28), indicate, as described above, a particular Base Syllable in INSTB 
20262. Bits 0—25 {CPC{0— 25)) of CPC 20270 indicate 32 bit words, read into INSTB 20262 as IBWO and 
eo 1BW1, of a sequence of SINs. CPC 20270 pointer is updated each time a parse operation reading a Base 
Syllable from INSTB 20262 is executed. As previously described, these parsing operations are performed 
under microinstruction control from FUSITT 11012. 

Conceptually, CPC 20270 is organized as a twenty-^ix bit counter, containing CPC (0—25), with a three 
bAt register appended on the low order side, as CPC (26—28). This organization is used because CPC 
6s (26—28) counts INSTB 20262 Base Syllables parsed and must be incremented dependant upon current 
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Name Syllable %e K stored CSSR 24112. CPC {0—25)^ however^ counts successive thirty-two bit words of a 
sequence of SINs and may ther^y be implemented as a binary counter. As shown in Rg. 241, CPC (26—28) 
is loaded from output of CPCMUX 241 18, A first input of CPCMUX 241 1 8 is connected from bits 29 to 31 of 
JPD Bus 10142. This input to CPC (26—28) from JPD Bus 10142 is provided to allow CPC 20270 to be loaded 
^ from JPD Bus 10142, for example when loading CPC 20270 with an initial pointer value. Second Input of 
CPCMUX 24118 is from output of CPCALU 24120 and is the path by which CPC (26—28) is incrememed as 
successive Base Syllables are parsed from INSTB 20262. A first input of CPCALU 24120 Is CPC (26—28) 
from CPC 20270, Second Input of CPALU 24120 is a dual Input from CSSR 24112. Rrst input from CSSR 
24112 is logic 1 in the least significant bit position, that is in position corresponding to CPC (28). This Input 
18 used when single Base Syllables are parsed from IIMSTB 20262. for example in an eight bit SOP or an 
eight bit Name syllable. CSSR 241 12's first input to CPCALU 241^ increments CPC (0—32) by eight, that Is 
one to CPC (26—28), each time a single Base Syllable is parsed from INSTB 20262. Second input to CPCALU 
24120 from CSSR 241 12 is K, that is current Name Syllable size. As previously described, K may be eight 
twelve, or axteen. CPC (26—28) is thereby incremented by one when K equals eight and Is incremented by 
two when K equals twelve or sixteen. As shown in Fig. 241, K is loaded into CSSR 24112 from JPD Bus 
10142. 

CPC (0—25), as described above, operates as a twenty-sbc bit counter which is incremented each time 
CPC (25—28) overflows. CPC (0—25) is incremented by carry output of CPCALU 24120. In actual 
implementation, CPC 20270 is organized to reduce the number of integrated circuits required. CPC (1—25) 
Is constructed as a counter and Inputs of CPC 11—25) counter are connected from bits 1 to 24 of JPD Bus 
10142 to allow loading of an initial value of CPC 20270 pointer. CPC (0) and CPC (26—28) are Implemented 
as a four bit register. Operation of CPC (26—28) portions of this register have been described above. Input 
of CPC (0) portion of this register is connected from output of CPCOS 241 1& CPCOS 241 16 is a multiplexer 
having a first Input connected from bit 0 of JPD Bus 10142. This input from JPD Bus 10142 Is used, for 
^ example, when loading CPC 20272 with an Initiai pointer value. Second input of CPCOS 241 16 is overflow 
output of CPC (1—25) counter and allows CPC (0) portion of the four bit register and CPC (1—25) counter to 
operate as a twenty-six bit counter. 

Finally, as shown in Rg 241, output of CPC 20270 may be loaded into IPC 20272. An initial CPC 20270 
pointer value may therefore be written Into CPC 20270 from JPD Bus 10142 and subsequently copied Into 
^ IPC 20272, 

Referring again to PARSER 20:^, as described above PARSER 20264 reads, or parses, basic syllables 
from INSTB 20262 to NAME Bus 20224. Input of PARSER 20264 Is a sixteen bit word comprised of an eight 
bit odd numbered Base Syllable, 8S0, and an eight bit even numbered Base Syllable, BSE. Depending upon 
whether PARSER 20264 is parsing an eight bit SOP, an eight bit Name syllable, a twelve bit Name syllable, 
^ or sbcteen bit Name sytlabie, PARSER 20264 may select BSD, BSE, or both BSO and BSE, as output onto 
NAME Bus 20224. 

if PARSER 20264 is parsing Name syllables and K is not equal to eight, that is equal to twelve or sixteen, 
PARSER 20264 transfers both BSO and BSE onto NAME Bus 20224 and determines which of BSO or BSE is 
most sign'fftcant The decision as to whether BSO or BSE is most significant is determined by CPC (28). If 
<^ CPC (28) indicates BSO is most significant BSO is transfen^d onto NAME Bus 20224 bits 0 to 7 
(NAME(0— 7)) and BSE onto NAME Bus 20224 bits eight to fifteen (NAME(8— 15)). If CPC (28) indicates BSE 
Is most significant, BSE is transfen-ed onto NAME (0—7) and BSO onto NAME (8—15). This operation 
Insures that Name syllables are parsed onto NAME Bus 20224 in the order in which occur In the SIN stream. 
If PARSER 20264 is parsing Name syllables of Syllable Size K = 8, PARSER 20264 will select either BSO 
^ or BSE, as indicated by CPC (28), as output to NAME {0—7). PARSER 20264 will place O's on NAME (8—15). 

If PAR^ 20264 is parang SOPs of eight bits, PARSER 20264 will select BSO or BSE as output to 
NAME (0—7) as selected by CPC (28). PARSER 20264 will place O's onto NAME (8—15). Concurrently, 
PARSER 20264 will generate OPREGE to OPCODEREG 20268 to enable transfer of NAME (0—7) into 
OPCODEREG 2026a OPCODEREG 20268 is not loaded when PARSER 20264 is parsing Name syllables. The 
so microinstruction input from FUSITT 11012 which controls PARSER 20264 operation also determines 
whether PARSER 20264 Is parsing an SOP or a Name syllable and controls generation of OPREGE. 

Operation of NC 10226, which receives Name syllables as address inputs from NAME Bus 20224, has 
been discussed previously with reference to MEMINT 20212. Name Trap (NT) 20254 is connected from 
NAME Bus 20224 to receive and capture Name syllables parsed onto NAME Bus 20224 by PARSER 20264. 
^ Operation of NT 20254 has been also previously discussed with reference to MEMINT. 

b.b.b. Fetch Unit Dispatch Table 11010, Execute Unit Dispatch Table 20266 and Operation Code 
Register 20268 (Bg. 242) 

As previously described, CS 10110 ts a multiple language machine. Each program written In a high 
60 level user language is compiled into a corresponding S-Language program containing S-Language 
Instructions referred to as SOPs. CS 10110 provides a set or dialect, of microcode Instructions, referred to 
as S-interpreters (SlNTs) for each S-Language. SINTs interpret SOPs to provide corresponding sequences 
of microinstructions for detailed control of CS 10110 operations. CS 10110's SIlVfTs for Fit 10120 and EU 
10122 operations are stored, respectively, in FUSrrT i 1012 and in a corresponding control store memory In 
& EU 10122, described in a following description of EU 10122. Each SINT comprises one or more sequences 
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of microinstructions, each sequence of microinstructions corresponding to a particular SOP In a particular 
S-Unguage dialect. Fetch Unit S-lnterpr6ter Dispatch Table {RJSDT) 1 1010 and Execute Unit ^interpreter 
Dispatch Table (EUSDT) 20256 contain an S-lnterpreter Dispatcher (SD) for each S-Language dialect Each 
SD is comprised of a set of SD Pointers (SDPs) wherein each SDP in a particular SD corre^nds toa 

s particular SOP of that SD dialect Each SDP is an address pointing to a location, in FUSITT 11012 or EUSITT, 
of the start of the corresponding sequence of microinstructions for interpreting the SOP corresponding to 
that SDP. As will be described further below, SOPs received and stored In OPCODEREG 20268 are used to 
generate addresses into RJSDT 11010 and EUSDT 20266 to select corr^ponding SDPs. Those SDPs are 
then provided to FUSITT 11012 through ADR 20202, or to EUSITT through EUDIS Bus 20206, to select 
corresponding sequences of microinstructions from FUSITT 11012 and EUSITT. 

Referring to Fig. 242, a more detailed block diagram of OPCODEREG 20268, FUSDT 1 1010, and EUSDT 
20266 is shown. As ^own therein, OPCODEREG 20268 Is comprised of OP-Code Latch (LOPCODE) 24210, 
Dialect Register mDlAL) 24212, Load Address Register (LADDR) 24214, and Fetch Unit Dispatch Encoder 
(FUDISENC) 24216. Data inputs of LOPCODE 24010 are connected from NAME Bus 20224 to receive SOPs 

« parsed from INSTB 20262. Load inputs of RDIAL 24212 are connected from Bits 28 to 31 of JPD Bus 10142. 
Outputs of LOPCODE 24210, RDIAL 24212 and LADDR 24214 are connected to inputs of FUDISENC 24216. 
Outputs of FUDISENC 24216 are connected to address inputs of FUSDT 11010 and EUSDT 20266. 

FUSDT 11010 is comprised of Fetch Unit Dispatch RIe (FUDISF) 24218 and Algorithm Rle (AF) 24220. 
Address inputs of FUDISF 24218 and AF 24220 are connected, as previously described, from address 

20 outputs of FUMSENC 24216. Data load inputs of FUDISF 24218 and fi^ 24220 are connected from, 
respectively, BHs 10 to 15 and Bits 16 to 31 of JPD Bus 10142. SDP outputs of FUDISF 24218 and AF 24220 
are connected to ADR Buses 20202. . . 

EUSDT 20266 is comprised of Execute Unit Dispatch Ffle (EUDISF) 24222 and Execute Unrt Dispatch 
Selector (EUDISS) 24224. Address Inputs of EUDISF 24222 are, as described above, connected from outputs 

^ of FUDISENC 2421 6. Data load inputs of EUDISF 24222 are connected from Bite 20 to 31 of JPD Bus 1 0142. 
Inputs of EUDISS 24224 are connected from SDP output of EUDISF 24222, from Bits 20 to 31 of JPD Bus 
10142, and from Microcode Literal (mLTT) output of FUSITT 11012. SDP outputs of EUDISS 24224 are 
connected to EUDIS Bus 20206. ^ ^ . . 

As previously described, OPCODEREG 20268 provides addresses, generated from SOPs loaded mto 

30 OPCODEREG 20268, to FUSDT 1101 0 and EUSDT 20266 to select SDPs to be provided as address inputs to 
RJSmr 1 1 01 2 and EUSPTT. LOPCX)DE 24210 receives and stores eight bit SOPs parsed from INSTB 202^ as 
described above. OPCODEREG 20^ also provides addresses to FUSDT 11010 and EUSDT 20266 to load 
FUSDT 11010 and EUSDT 20266 with SDs for S-Language dialects currently being utilized by CS 10110. 
LOPCODE 24210 and RDIAL 24212, as described below, provide addresses to FUSDT 11010 and EUSDT 

35 20266 when translating SOPs to SDPs and ADDR 24214 provides addresses when FUSDT 1 1010 and EUSDT 
20266 are being loaded with SDs, ^ . 

Referring first to LADM 2^14, LADDR 24214 has an ^ght bit counter. Addresses are provided to 
FUSDT 11010 and EUSDT 20266 from LADDR 24214 only when FUSDT 11010 and EUSDT 20266 are being 
loaded with SDs, that is groups of SDPs lor S-Language dialects currently being utilized by CS 10110. 

40 During this operation, output of UUMDR 24214 ts enabled to FUSDT 11010 and EUSDT 20266 by microcode 
control signals (not shown for clarity of presentation) from FUSITT 11012. Selection between FUDISF 
24218, AF 24220, and EUDISF 24222 to receive addresses Is similarly provided by microinstruction enable 
signals (also not shown for clarity of presentation) provided from FUSITT 11012. These FUSDT 11010 and 
EUSDT 20266 address enable inputs may select, at any time, any or all of FUDISF 2^18, AF 24220, or 

46 EUDSF 24222 to receive address inputs. SDPs to be loaded into FUDISF 24218, AF 24220, and EUDISF 24222 
are prowded, respectively, from Bits 10 to 15 (JPD{10— 15)), Bits 16 to 31 {JPD(16-^1]), and Bits 20 to 31 
(JPD(20— 31 )) of JPD Bus 1 0142. Address contents of LADDR 24214 are successively incremented by one as 
successive SDPs are loaded into FUSDT 1 1010 and EUSDT 20266. incrementing of LADDR 24214 is, again, 
controlled bv microinstruction control inputs from FUSiTT 11012. 

50 Address inputs to FUSDT 11010 and EUSDT 20266 during interpretation of SOPs are provided from 
LOPCODE 24210 and RDIAL 24212. LOPCODE 24210 is a register counter having, as descrjt>ed above, data 
inputs connected from NAME Bus 20224 to receive SOPs from PARSER 20264. In a first mode, LOPCODE 
24210 may operate as a latch, loaded with one SOP at a time from output of PARSER 20264. In a second 
mode, LOPCODE 24210 operates as a clock register to receive successive eight bit inputs from low order 

gg eight bits of NAME Bus 20224 (NAME(8— IS)), Loading of LOPCODE 24210 is contolled by micrainshruction 
control outputs (not shown for clarity of presentation) from FUSITT 11012. 

As will be described further below, eight bit SOPs stored in LOPCODE 24210 are concatenated with the 
output of RDIAL 24212 to provide addresses to FUSDT 11010 and EUSDT 20266 to select SDPs 
corresponding to particular SOPs. That portion of these addresses provided from LOPCODE 24210, that is 

gQ the eight bit SOPs, selects particular SDPs within a particular SD. Particular SDs are selected by that portion 
of these addresses which is provided from the contents of RDIAL 24212. 

RDIAL 24212 receives and stores four bit Dialect Codes indicating the particular S-Language dialect 
currently being used by CS 101 10 and executing the SOPs of a user's program. These four bit Dialect Codes 
are provided from JPD Bus 10142, as JPD (28—31). Loading of RDIAL 24212 with four bit Dialect Codes is 

gg controlled by microinstruction control signals provided form FUSITT 11012 (not shown for clarity of 
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presernation). 

Four bit Dialect Codes in RDIAL 24212 define partitions in FUDiSF 24218, AF 24220 and EUDISF 24222. 
Each partition contains SDPs for a different S-Language dialect, that is contains a different SD. RJDISF 
24218, AF 24220 and EUDISF 24222 may contain, for example, eight 128 word partitions or four 256 word 
* partitions. A single bit of Dialect Code, for example Bit 3, defines whether FUDISF 24218, AF 24220, and 
EUDISF 24222 contain four or eight partitions. If FUSDT 1 1 010 and EUSDT 20266 contain four partitions, the 
two most significant bits of address into FUSDT 1 101 0 and EUSDT 20266 are provided from Dilect Code Bits 
1 and 2 and determine which paitition is addressed. The lower order eight bits of address are provided 
from LOPCODE 24210 and determine which word In a selected partition is addressed. If FUSDT 11010 and 
10 EUSDT contain eight partitions, the three most agnificant bits of address into FUSDT 11010 and 
EUSDT 20266 are provided from Bits 0 to 2 of Dialect Code, to select a particular partition, and the lower 
seven bits of address are provided from LOPCODE 24210 to select a particular word in the selected 
partition. 

As described above. LOPCODE 24210 eight bit output and RDIAL 24212*8 four bit output are 

IS concatenated together, through FUDISENC 24216, to provide a ten bit address input to FUSDT 1 1010 and 
EUSDT 20266. FUDISENC 24216 is an encoding circuit and wilt be described further below with reference to 
FUDISF 24218. As previously described, selection of FUDISF 24218, AF 24220, and EUDISF 24222 to receh/e 
address inputs from RDIAL 24212 and LOPCODE 24210 is controlled by microinstruction control enable 
inputs provided from FUSITT 11012 (not shown for clarity of presentation). 

20 Referring to FUSDT 11010, both FUDISF 24218 and AF 24220 provide SDPs to FUSrmi012. but do so 
for differing purposes. In general, microinstruction control operations may be regarded as falling Into two 
classes. Rrst, there are those microinstruction operations which aro generic, that is general In nature and 
used by or applying to a broad variety of SOPs of a particular dialect or even of many dialects. An example 
of this class of microinstruction operation is fetches of operand values. FUDISF 24218 provides SDPs for 

25 this dass of microinstruction operations. As described below, FUDISF 24218 is a fast access memory 
allowing a single microinstruction control output of FUSITT 1 1 012 to parse an SOP from INSTB 20262 into 
LOPCODE 24210, and a corresponding SDP to be provided from FUDISF 24218. That is, an SOP of this 
generic dass may be parsed from INSTB 20262 and a corresponding SDP provided from FUDISF 24218 
during a single system dock cyde. Operation of FUDISF 24218 thereby enhances speed of operation of JP 

30 10114, in particular at the beginning of execution of new SOPs. 

The second dass of microinstruction operations are those specffic to particular SINTs or to particular 
groups of SINTs. These groups of SINTs may reside entirely within a particular dialect, for example 
FORTRAN, or may exist within one or more dialects, SDPs for this dass of microinstruction operation are 
provided by AF 24220. As described furti^er below, AF 24220 is slower than FUDISF 24218, but Is larger. In 

3S general, AF 24220 contains SDPs of microinstruction sequences specific to particular SINTs. In general, 
generic microinstruction operations are performed before th^^e operations specific to particular SINTs, so 
that SDPs are required from AF 24220 at a later time than those from FUDISF 24218. SDPs for specific SINT 
operations may therefore be provided from lower speed AF 24220 without a penalty In Qpe&i of execution 
of SOPs. 

40 Referring again to FUDISF 24218, FUDISF 24218 is a 1,024 word by 6 bit fast access by polar memory. 
Each word contained therein, as described above, is an SDP, or address to start of a corresponding 
sequence of microinstructions in FUSITT 1 1012. As will be described further below, FUSITT is an 8K {8192) 
word memory. SDPs provided by FUDISF 24218 are each, as described above, 6 bits wide and may thus 
«ldress a limited, 32 word area of FUSITT 1 1012's address space. FUDISF 24218 is enabled to provide SDPs 

45 to FUSnr 11012 by microinstruction control signals <rKyt shown for darity of presentation) from FUSHT 
11012- FUDISF 24218 six brt SDPs are encoded by FUDISENC 24219 to address FUSITT 1 1012 address space 
In increments of 4 microinstructions, that is in increments of 4 addr^ locations. FUDISF 24218 SDPs 
thereby address 4 microinstructions at a time from FUSITT 11012*5 microinstruction sequences. As will be 
described further below, mPC 20276 generates successhre microinstruction addresses to FUSITT 1 1012 to 

so select successive microinstructions of a sequence following an initial microinstruction selected by an SDP 
from FUSDT 11010. An FUWSF 24218 SDP will thereby select the first microinstruction of a 4 
microinstruction block, and mPC 20276 will select the following 3 microinstructions of that 4 
microinstruction sequence. A 4 microinstruction sequence may therefore be executed in line, or 
sequentially, for each FUDISF 24218 SDP provided In response to a generic SOP. FUDISENC 24219 encodes 

55 FUDISF 24218 six bit SDPs to select these 4 microinstruction sequences so that the least significant bit of 
these SDPs occupies the 24 bit of FUSITT 11012 address Inputs, and so on. The two least signrficant bits of 
an FUSITT 11012 address, or SDP, provided from FUDISF 24218 are forced to 0 while the ninth and higher 
bets may be hard-wired to define any particular block of 128 addresses In FUSITT 1 1012. This hard^ring of 
ttie most significant bits of FUSITT 11012 addresses from FUDISF 24218 allows a set of generic 

50 microinstruction sequences selected by FUDISF 24218 to be located as desired within FUSFTT 11012's 
address space. FUDISENC 24219 Is comprised of a set of driver gates. 

As previously described, SDPs for generic microinstructions currentiy being utilized by CS 10110 in 
executing user's programs are written into FUDISF 24218 from Bits 10 to 15 of JPD Bus 10142 
{JPD(ia— 15)). Addresses for loading SDPs into FUDISF 24218 are provided, as previously described, from 

€5 lADDR 24214. LADDR 24214 is enabled to provide load addresses, and FUDISF 24218 is enabled to be ^ 
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written Into, by microinstmction control signals (not shown for darity of presentation) provided from 

''"^S'to AF 24220, as previously described AF 24220 is of larger capacity than FUDISF 24218, but 
ha« aWtime AF 24^0 is a 1 024 word by 1 5 bit memory. In general, 2 cloclc cycles are required 

second dock cycle, AF 24220 Is addressed to provide a corresponding SDP. S'>^ P™J'°f ~ liTifi 
each 15 bits In width and thus capable of addressing a larger address space than that y 
^•ousFdScribed, FUSITT 11012 is an 8K word memory If FUSITT 11012 ^^^^^^^^^^^ZZ^S^ 
SDP refeiTing toan address locatkw outside of FUSnT11012's address space, FUSITT11012 will generate 
w fmiiroS^on Not in Control Store output to EVENT 20284 as describ^ ^„!^r^Jr«jrnS 
Idp rSultmg in this event will then be used to address cerlai«r;K30.'^«.on sequences ^ored m MEM 
10112. Thesl microinstructions wll then be executed from MEM lOl". rather than from FU^^ 
This oDeration allows certain microinstruction sequences, for example rarely used microinstruction 
2;uenSrremarfnSl0112.thusfreeingAF24220andFUSnT11012's8ddr^^ 

« frequeijlyused SO^.^^ ^ ^ ^ ^ 5,^^ ^^^^^ being used by (S 1 01 18 in 

executing user's programs, fram Bits 16-31 of JPD Bus 10142 (JPD(16-31)). Also as previously discussed, 
^dresses to load SDPs Irrto AF 24220 are provided from LADDR 24214. LADDR 24214 Is enabl^ to provide 
load addresses and AF 24220 to receive SDPs, by microinstruction control signals (not shown for danty of 

20 presentation) provided from FUSnri 1012. « en mioo crko. 

Referring finally to EUSDT 20266. SDPs may be provided to EU 10122 from 3 sources. EU 10122 SDPs 
may be provided from EUDISF 24222. from JPD Bus 10142 or from literal fields of microinstructions 
provided from FUSITT 1 1 012. EUDISF 24222's SDPs are each 12 Wts in wdth and compnse 9 bits of address 
Into EUSfTT and 3 bits of operand format information. 

» EUDISF 24222 is 1.024 word by 12 bit memory. As previously described ad*««^to r^d SDPs fr^ 
EUDISF 24222 are provided from OPCODEREG 20268 by concatenating a 4 bit Dialect Code frorn RDIAL 
2421 2 and an 8 bK SOPfrom LOPCODE 24210, SDPs provided by EUDISF 24222 are provided as a first input 

*°^S&^Sa4isamuMexer.Asjustdescribed.afirstlnputrfEU0^^^^ 
30 24222. A second 12 bit Input of EUDISS 24224 is provided from B«te20 to 31 JPD Bu^^^ 
(JPD{20-31)). A third input of EUDISS 24224 is a 12 bit input provided « '""'^'^S «,^i^o 
11012 microinstruction output EUDISS 20224 selects one of these 3 inputs to be tranrfernrt on EUDI5 Bus 
to provided as "n execute unit SDP to EUSITT. Selecdon ^"D'SS 5^»^«P"H;i 

provided by microinstruction control signals (not shown for clarity of presentaflon) provKled from FUSnr 

* previously described. EUDISF 24222 is loaded, with SDPs for S-Lenguage *alecte wrrwrtly tolng 

used^ CS 10110, from Bits 20 to 31 of JPD Bos 10142 (JPD(20-31)). Address^ to loadSDPsmto EUDISF 
^2 are provided, as previously described, from LADDR 20214. FUSITT 11012 provid^ ««bte agrete 
Sot shown for clarfty of presentJfionl to LADDR 24214 and EUDISF 24222 to enable wntmg of SDPs into 

^"'¥heSSureandoperetionofFUCTL20214drcuitryforfetd,-m^^^^^ 

provide Name syllables and SOPs, and for interpreting SOP to P^^'^^e SDPs to FUSTTT ^W2 

ftom FUSDT 1 1010 and EUSDT 20266, have been descnbed above. As descnbed al>we. SW^J pi^^ by 

FUSDT 11010 and EUSDT 20266 are initial, or starting, addresses pointing to first microlnstrtwdons of 

^ Squemil of mrcroinstroctio^^^ Addresses for microinsmictions following 

are provided by FUCTL 20214's next address generator circuitry which may indude mPC 20276, K^A^ 
M27TrH^R 2CC80 and PNREG 20282, EVENT 20284 and SITTNAG 20286. mPC 20276, 8RCASE 20278, 
REPCTB 20280 and PNREG 20282, and SITTNAG 20286 are primarily concerned 'T* 
addresses during execution of microinstruction sequences in response to SOPs and wUI be descnbed next 

so below EVENT 20284 and other portions of FUCTL 20214's circuitry are more concerned with generation of 
microinstruction sequences with regard to CS lOIIO's internal medianisms operations and will be 
described in a later description. EU 10122 also includes next address generation circuitry and this circuitry 
will be described in a following description of EU 10122. 

SB C.CX. NextAddress Generator 24310 (Fig. 243) 

As stated above, in FU 10120 first, or initial, microinstuctions of microinstmction sequenc^ for 
interpreting SOPs are provided by FUSDT 11010. Subsequent addresses of miCTOif^ructions >?«th'n these 
s5S are. in general, provided by mPC 20276 and BRCASE 20278. mPC 20276. as described further 
bdSw" ^Kiuential addresses for selecting sequential microinstructions of m.croms^rurtion 

» seauenoes BRCASE 20278 provides addresses for selecting microinstructions when a microinstruction 

* ^"^rmSrucdon cSseoperetion is required, ^^^li^^.^^f/^^^^lr^l^^^ 

tor writing, or loading, of microinstruction sequences into FUSITT 11012. Other portions of FUCTL 20214 
drcuitry, for example EVENT 2(«84. provides microinstmction sequence selection ^dd"^ to sol^ 
microi^ruction sequences for controlling operation of CS 101 10's interna^ SSTSSTL^r^ 

65 selects behween these microinstruction address sources to provide to FUSITT 11012 those addresses 
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required to select microinstructions of the operation to be cun^mJy executed by CS 10110, 

Referring to Rg. 243, a partial block diagram of FU 10120's Next Address Generator (NAG) 24310 Is 
shown. In addition to FUSDT 11010. NAG 24310 includes mPC 20275, BRCASE 20278, EVENT 20284, 
REPCTR 20280 and PNREG 20282, a part of RCWS 10358, and SfTTNAS M286. EVE^^r 20284 is, as 
^ described above, prtmarily concerned with execution of microinstruction sequences for controlling CS 
10110 interna! mechanisms. EVENT 20284 ^ shown herein only to illustrate its relationships to other 
portions of NAG 24310. EVENT 20284 will be described further in a following description of FUCTL 2021 4's 
drcuitry* contfxjlling CS 10110's internal mechanisms. Similariy, operation of RCWS 10358 will be 
described in part in the presem description of NAG 24310, and In part in a following description of control 
of CS 101 10's Internal mechanisms. 

Referring first to NAG 24310's structure, interconnections of FUSDT 11010, RCWS 10358, mPC 20276, 
BRCASE 20278, REPCTR 20280, PNREG 20282, EVENT 20284, and SITTNAS 20286 have been previously 
described with reference to Fig. 20Z NAG 24310's structure will be described below only wherein Rg. 243 
differe from Rg. 202. 

Refening first to SITTNAS 20286, SITTNAS 20286 is shown as comprised of EVENT Gate (EVNTGT) 
24310 and Next Address Select Multiplexer {NASMUX) 24312. NASMUX 24312 is comprised of NAS. 
Multiplexer A (NASMUXAI 24314, NASMUXB 24316, NASMUXC 24318, and NASMUXD 24320. Outputs of 
EVNTGT 24310 and NASMUXA 24314 to NASMUXD 24320 are ORed to CSADR 20204 to provide 
microinstruction sel^on addresses to FUSITT 11012. 

20 ADR 20202 is shown In Rg. 243 as comprised of nine buses. Address A (ADFIA) Bus 24322 to Address I 
(AORf) Bus 2 4338. O utput of EVENT 20284 is connected to Input of EVNTGT 24310 by ADRA Bus 24322. 
Outputs of REPCTR 20280 and PNREG 20282 and output of AF 24220 are connected to inputs of NASI WIUXA 
24314 by, respectWely, ADRB Bus 24324 and ADRC Bus 2432& Outputs of RCWS 10^ and FUOISENC 
24219 are connected to inputs of NASMUXB 24316 by, respectively, ADRD Bus 24328 and ADRE Bus 24330. 

25 Outputs of BRCASE 20278 and second output of mPC 20276 are connected to inputs of NASMUXC 24318 
by, respectively, ADRF Bus 24332 and ADRG Bus 24334. Second output of mPC 20276 and JAM output of 
NC 10226 are connected to inputs of NASMUXD 24320 by, respecth^ely, ADRH Bus 24336 and ADR1 Bus 
24338. ADR 20202 thus comprises a set of buses connecting microinstruction address sources to inputs of 
SITTNAS ^1286. 

30 Refening to mPC 20276, mPC 20276 is comprised of Micro-Program Counter Counter (mPCC) 24340 
and Micro-Program Counter Arithmetic and Logic Unit (mPCMXI) 24342. Data Input of mPOC 24340 is 
connei^ed from CSADR Bus 20204. Output of mPCC 24340 Is connected to a first input of mPCALU 24342 
and is mPC 20276's third output to BRCASE 20278, Second input of mPCALU 24342 is a fifteen binary 
number set. for example by hard-wiring, to be binary one. Output of mPCALU 24342 comprises wPC 

35 20276's first output, to RCWS 10358, and mPC 20276's second output, to inputs of NASMUXC 24318 and 
NASMUXD 24320. 

BRCASE 20278 is shown in Rg. 243 as comprising IVIask and Shift Multiplexer (MSMUX) 24344, Case 
Masicand Shift Logic (CASEMS) 24346, Branch and Case Multiplexer (BCMUX) 24348 and Branch and Case 
Arithmetic and Logic Unit {BCALU) 24350. A first input of MSMUX 24344 (AONBC, not previously shown) is 

4a connected from output of AONGRF 20232. A second input of MSMUX 24344 (OR^MUXR, not previously 
shown) Is connected from output of OFR\^UXR 23812. Output of MSMUX 24344 is connected to input 
CASEMS 24346, and output of CASEMS 24346 is connected to a first input of BCMUX 24348. A second input 
of BCMUX 24348, BLTT is connected from a literal field output of RJSITT 11012's microinstmction output 
Output of BCMUX 24348 and third output of mPC 20276, from output of mPCC 24340, are connected, 

45 respectively, to first and second inputs of BCALU 24350. Output of BCM.U 24350 comprises BRCASE 20278 
outputs to NASMUXC 24318. 

An address to ^lect a next microinstruction may be provided to FUSITT 1 1012 by SITTNAS 20286 from 
any of eight sources. Rrst source is output of mPC 20276. Output of mPC 20276 is referred to as Micro- 
Program Count Plus 1 <mPC+1) and Isfrfteen bits of address. Second source is from EVENT 20284 and is 

so comprised of five bits of address. Third source is output of FUDISP 24218 and FUDISENC 24219 and, as 
previously described, is comprised of sbc bits of address. Fourth source is output of AF 24220 and, as 
previously described, is comprised of frfteen bits of address. Fifth source is outwit of BRCASE 20278. 
Output of BRCASE 20278 is referr^ to as Branch and Case Address (BRCASEADR) and comprises fifteen 
bits of address. Sbcth source is an output of RCWS 10358. Output of RCWS 10358 is referr^ to as RCWS 

ss Address (RCWSADR) and is comprised of fifteen bits of address. Seventh source is REPCTR 20280 and 
PNREG 20282 whose outputs (REPPN) together comprise fifteen bits of address. Finally, eighth source is 
JAM input from NC 10226, which comprises fwe bits of address. These address sources differ in number of 
bits of address thetthey provide, but a microinstruction address gated onto CSADR Bus 20202 by SITTNAS 
. 20286 always comprises Meen bits of address. If a particular source applies iewer than fifteen bits, that 

60 address is extended to fifteen bits by SITTNAS 20286. In general, extension of address bits may be 
performed by hard-wiring of additional address input bits to SfTTNAS 20286 from each of these sources 
and win be described further below. 

Referring to mPC 20276. mPCC 24340 is a fifteen bit register and mPCALU 24342' is a fifteen bit ALU. 
mPCC 24340 is, as described above^ connected from CSADR Bus 20204 and is sequemiaily-loaded with a 

65 microinstruction address currently being presented to FUSITT 11012. mPCC 24340 will thus contain the 
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address of the currently executing microinstruction. mPCALU 24342 Is dedicated tojncrementing the 
addr^s contained in mPCC 24340 by one. mPG->- t output of mPCALU 24342 will thereby always be address 
of next sequential microinstruction. mPC+l is, as described above, a fifteen bit address and Is thus not 
extended in SITTNAS 20286. 
* Referring to BRCASE 20278, as described above BRCASE 20278 provides next microinstruction 
address^ for mPC 20276 Relative Branches and for Case Branches. Next microinstruction addresses for 
microprogram Relative Branches and for Case Branches are both generated as addresses relative to 
address of currently executing microinstruction as stored In mPCC 24340, but differ In the manner in which 
these relative addresses are generated. Considering first Case Branches, Case Branch addresses relative to 
a currently executing microinstruction address are generated, in part, by MSMUX 24344 and CASEMS 
24346. As described above, MSMUX 24344 which is a multiplexer receives two inputs. Rrst input is AONBC 
from output of AONGRF 20232 and second input is OFFMUXR from output of OFFMUXR 23812, Each of 
these inputs is eight bits, or one byte, in width. Acting under control of microinstruction output from 
FUSITT 1 101 2, MSMUX 24344 selects either input AONBC or input OFFMUXR as an eight bit output to input 

IS of CASEMS 24346. CASEWIS 24346 is a Mask and Shift circuit similar in structure and operation to that of 
FIU 20116 but operating upon bytes rather than thirty-two bit words. CASEMS 24346, operating under 
microinstruction controi from FUSITT 11012, manipulates eight bit input from MSMUX 24344 by masking 
and shifting to provide eight bit Case Value (CASEVAL) output to BCMUX 24348, CASEVAL represents a 
micioinstruction address displacement relative to address of a currently executing microinstruction and, 

^ being an eight bit number, may express a displacement of O to 255 address locations in FUSITT 1 1012, 
BCMUX 24348 is an eight bit multiplexer, simitar In structure and operation to MSMUX 24344, and is 
controlled by microinstruction Inputs provided from FUSfTT 11012. In executing a case operation, BCMUX 
24348 selects CASEVAL Input to MCMUX 24348's output to first input of BCALU 24350. BCALU 24350 Is a 
dxteen bit arithm^c and logic unit Second Input of BCALU 24350 Is fifteen bit address of cun^ntly 

^ executing microinstruction from mPCC 24340, BCALU 24350 operates under microinstruction control 
provided liom FUSITT 11012 and. In executing a Case operation, adds CASEVAL to tlie address of a 
currently executing mic^instruction. During a Case operation, carry input of BSALU 24350 is forced, by 
* microinstruction control from FUSITT 11012, to one so that BCALU 24350*8 second input Is effectively 
mPC+1. or address of currendy executing microinstruction plus 1. Output BRCASEADR of BCALU 24350 

30 ^fin\\ thereby be fifteen bit Case address which is between one and 256 FUSITT 11012 address locations 
higher than the address location of the currently executing microinstnjction. The actual case value address 
displacement from the address of the currently executing microinstruction is determined by elUier input 
AONBC or input OFFMUXR to MSMUX 24344, and these mask and shift operations ana performed by 
CASEMS 24346* . 

3S Case operations as described alxyve may be used, for example. In interpr^ng and manipuleting CS 

10110 table entries. For example, Name Table Entries of Name Tables 10350 contain flag fields carrying 
information regarding certain operations to be performed In resolving and evaluating those Name Table 
Entries. These operations may be implemented as Case Branches in microinstruction sequences for 
resolving and evaluating those Name Table Entries. In the present example, during resohre of a Name 

40 Table Entry the microinstruction sequence for performing that resohre may direct a byte of that Name Table 
Entry's flag field to be read from AONGRF 20232, or OFFMUXR 23812, and through MSMUX 24344 to 
CASEMS 24346. That microinstruction sequence will then direct CASEMS 24346 to shift and mask that flag 
field byte to provide a CASEVAL That CASEVAL will have a value dependent upon the ftags within that flag 
field byte and, when added to mPC+1, will provide a FUSITT 11012 microinstniction address for a 

4S microinstruction sequence for handling that Name Table Entry in accordance with those flag tto. 

As described above, BRCASE 20278 may also gwierats microinstruction addresses for Branches 
occuning within execution of a given microinstruction sequence. In this case, microinstruction control 
signals from FUSITT 1 101 2 direct BCMUX 24348 to select BCMUX 24348's second input as output to BCALU 
24350. BCMUX 24348's second input is Branch Literal {BUT), As described above, BLIT is provided from a 

SO literal field of a microinstruction word from FUSITT 1101 2's microinstroction output. BUT output of BCMUX 
24348 is added to address of currentiy executing microinstruction from mPCC 24340, and BCALU 24350, to 
provide fifteen bit BRCASEADR of a microinstruction address branched to from the address of the currentiy 
executing microinstruction. BRCASEADR may represent, for example, any of four Branch Operations. 
Possible Branch Operations are: first, a Conditional Short Branch; second, a Conditional Short Call; third, a 

ss Long Go To; and, fourth, a Long Call. In each of these possible Branch Operations, BLIT is treated as the 
twos complement of the desired branch value, that is the microinstruction address offset relative to the 
address of the currently executing microinstruction. BLIT field may tiierefore be, effectively, added to or 
subtracted from the address of the currently executing microinstruction, to provide a microinstruction 
address having a positive or negative displacement from the address of the currentiy executing 

60 microinstniction. In a Conditional Short Branch or a Conditional Short Call, the fourteen bit literal field is a 
sign extended eight bit number. Both Conditional Short Branch and Conditional Short Call microinstruction 
addresses may therefore point to an address within a range of +127 to -128 FUSITT 11012 address 
locations of the address of the currentiy executing microinstruction. In the case of a Long Go To or Long 
Call, the BLIT field is a fourteen bit number representing displacement relative to the address of the 

€S currentiy executing microinstrudion. BRCASEADR may. In these cases, represent a FUSITT 11012 
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microinstruction address within a range of 4-8191 to -8192 FUSITT 1 1012 address locations of the address 
of the cun^ntly executing microinstruction. BRCASE 20278 thereby provides FU 10120 with capability of 
executing a full range of microinstruction sequence Case and Branch operations. 

Referring to RCWS 10358, as previously described RCWS 10358 stores information regarding 
^ microinstruction sequences whose execution has been halted. RCWS 10358 allows execution of those 
microinstruction sequences to be resumed at a later time. A return control word {RCW) may be written onto 
RCWS 10358 during any microinstruction sequence that issues a Call to another microinstruction 
' sequence. The calling microinstruction sequence may, for example, be aborted to service an event, as 
described further in a following description, or may result in a Jam. A Jam is a call for a microinstruction 
sequence which is fbrt^ed by operation of CS 101 10 hardware, rather than by a microinstruction sequence. 
RCWS 10358 operation with regard to CS 10110's internal mechanisms will be described in a following 
description of EN^NT 20284, STATE 20294, and MCWl 20290 and MCWO 20292. For purposes of ttie 
present discussion, that portion of a RCW concerned with Interpretation of SOPs contains, first, certain 
state information from FUSITT 11012 and, second, a retum address Into FUSfTT 11012. State that FUSITT 
11012 state is provided from STATE 20294, as described below, and that portion of a RCW containing 
FUSITT 11012 state information vwll be described in a following description. Microinstruction address 
portions of RCWs are provided from output of mPCALU 24342. This microinstruction address is the address 
of the microinstruction to which FU 10120 is to return upon retum from a Call. Event, or Jam. Upon 
occurrence of a Call or Jam, the microinstruction return address is mPC+1, that Is the address of the 

^ microinstruction after the microinstruction issuing the Call or Return. For aborted microinstruction 
sequences, the microinstruction retum address Is mPC, that is tiie address of the microinstruction 
executing at the time abort occurs. 

Upon retum from a call, service of an event or service of a jam, FU 10120 state flag portion of RCW is 
loaded into STATE 20294. Microinstruction retum address is provided by RCWS 10358 as fifteen bit 

^ RCWSADR to SITTNAS 202^ and is gated onto CSADR 20204. RCWSADR is provided to FUSITT 11012 to 
select the next microinstruction and is loaded into mPCC 24340 from CSADR 20204v 

As previously described, RCWS 10358 Is connected to JPD Bus 10142 by a bi-directional bus. RCWs 
may be written into RCWS 10358 from JPD Bus 10142, or read from RCWS 10358 to JPD Bus 10142. The 
fifteen bit next microinstruction address portion, and the single bit FUSITT 1 1012 state portion of RCW is 

30 written from or read to Bits 16 to 31 of JPD Bus 1 0142. FU 101 20 may write Present Bottom RCW or Previous 
RCW into RCWS 10358 from JPD &js 10142 and may read Present Bottom RCW, or Previous RCW, or 
another selected RCW, onto JPD Bus 10142. RCWS 10^ thereby provides a means for storing and 
returning microinstruction addresses of microinstruction sequences whose execution has been 
suspended, and a means for uniting and reading microinstruction address, and FUSITT 11012 state flags, 

35 from and to JPD Bus 10142. 

As previously described, REPCTR 20280 and PNREG 20282 provide microinstruction addresses for 
writing of microinstructions into FUSITT 1 1012. REPCTR 20280 is an eight bit counter and PNREG 20282 is a 
seven bit register. Eight bit output of REPCTR 20280 is left concatenated with seven bit output of PNREG 
20282 to provide fifteen bit microinstruction addresses REPPN. That is, REPCTR 202^ provides the eight 

40 low order bits of microinstruction address while PNREG 20282 provides the seven most significant bits of 

^ address. 

REPCTR may be loaded from Bits 24—31 of JPD Bus 1 0142, and may be read to Bits 24—31 of JPD Bus 
10142. In addition, the eight bits of microinstruction address in REPCTR 20280 may be Incremented or 
decremented as microinstmctions are written into FUSnT 11012. 
45 As described above, PNREG 20282 contains the seven most significant bits of microinstruction 

address. These address bits may be written Into PNREG 20282 from Bits 17—23 of JPD Bus 10142. Contents 
of PNREG 20282 may not in general, be read to JPD Bus 10142 and may not be incremented or 
decremented. 

Referring to JAM input to SITTNAS 20286 from NC 10226, certain Name evaluate or resolve operations 

so may result in jams. A Jam functions as a call to microinstruction sequences for servicing Jams and are 
forced by RJ 10120 hardware circuitry involved in Name syllable evaluates and resolves. 

JAM input to SITTNAS 20^ is comprised of six Jam address bits. Three bits are provided by NC 
10226 and three bits are provided from FUSITT 1 1012's microinstruction output as part of microinstruction 
sequences for corre^ng Name syllable evaluates and resolves. The.three bits of address from NC 10226 

ss fomn the most significant three bits of JAM address. One of these bits gates JAM address onto CSADR Bus 
20204 and is thus not a true address bit Output of FUSfTT 1 1012 provides the throe least significant bits of 
JAM address and specifies the particular microinstruction sequence required to service the particular Jam 
which has occurred. Therofore, during Name evaluate or resolves, the microinstruction sequences 
provided by FUSITT 11012 to perform Name evaluates or resolves spedfles what microinstruction 

60 sequOTces are to be initiated rf a Jam occurs. The three bits of JAM address provided by NC 10226 
determine, first, that a Jam has occurred and, second, provide two bits of address which, in combination 
with the three bits of address from FUSITT 11012, specify the particular microinstruction sequence for 
handling that Jam. JAM address inputs from NC 10226 and from FUSITT 11012 thereby provide six of the 
fifteen bits of JAM address. The remaining nine bits of JAM address are provided, for example, by hard- 

65 wired inputs to NASMUXD 24320. These hard-wired address bits force JAM address to address FUSHT . 
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11 01 2 in blocks of 4 microinstruction addresses, In a manner similar to address inputs to FUDISF 24218 and 

FU01SENC 24219. ^ r t -i u ^ >u 

Address inputs provided to SITTNAS 20286 from FUSDT 11010 have been previously described with 
respect to description of FUCTL 20214 fetch, parse, and dispatch operations. Address inputs provided by 
EVENT 20284 will be described in a following description of FUCTL 2021 4's operations with regard to C5 
101 10's internal mechanisms. . *cv/Ki-ri-x 

Referring finally to SfTTNAS 20286, as previously described SITTNAS 20286 is conipnsed of EVNTGT 
24310 and NASMUX 24312. Inputs are provided to NASMUX 24312, as described above, from FUSDT 
11010, mPC 20276, BRCASE 20278, RCWS 10358, REPCTR 20280 and PNREG 20282, and by JAM input. 
These inputs are, in general, provided with regard to FUCTL 20214's operations in fetching, parsing, and 
interpreting SOPs and Name syllables. These operations are thereby primarily directly concern^ with 
execution of user's programs, that is the execution of sequences of SlNs. NASMUX 24312 selects between 
these Inputs and transfera selected address inputs onto CSADR 20204 as microinstrurtion addresses to 
FUSITT' 11012 under microinstruction oontro! from microinstruction outputs of FUSITT 11012, 
Microinstruction address outputs are provided to SITTNAS 20286 from EVENT 20284 in response to Events, 
described further below, occurring In CS lOIWs operations in executing user's programs. These 
microinstruction addresses from EVENT 20284 are gated onto CSADR 20204, to select appropriate 
microinstruction sequences, by EVNTGT 24310. EVNTGT 24310 is separated from NASMUX 2431210 allow 
EVNTGT 24310 to over-ride NASMUX 24312 and provide microinstniction address to EVENT 20284 virtule 
20 NASMUX 24312 is Inhibited due to occurrence of certain Events. These Events are, in general, associ^ed 
with operation of CS 101 10's internal mechanisms and structure and operation of EVENT 20284, togemer 
witii STATE 20294, MCW1 20290, and MCWO 20292, and other portions of RCWS 10358, will be descniaed 
next below. 

25 CO. FUCTL 20214 Control Circuitry for CS 101 10 Internal Mechanisms {Figs. 244—249) 

Certain portions of FUCTL 20214's Control Circuitry are more directly concerned with operation of CS 
101 ICs internal mechanisms, for example CS 101 10 Stack Mechanisms. This circuitry may Include STATE 
20294, EVENT 20284. MCW1 20290 and MCWO 20292, portions of RCWS 10358, REG 20288. and Timers 
20296. These FUCTL 20214 control elements will be described next below, beginning witii STATE 20294. 

30 

a.a.a. State Logic 20:»4 (Figs. 244A— 244Z) 
In general, all CS 10110 operations, including execution of microinstructions, are controlled by CS 
101 10's Operating State. CS 101 10 has a number of Operating States, hereafter referred to as States, eadi 
State bdng defined by certain operations which may be performed in that State. Each of these States will 

35 be described further below. Current Stats of CS 101 10 is Indicated by a set of State Rags stored In a set of 
registers in STATE 20294. Each State is entered from previous State and is exited to a following Slate. Next 
State of CS 10110 is detected by random logic gating distributed throughout CS 10110 to detect certain 
conditions Indicating which State CS 10110 will enter next. Outputs of these Next State Detection gates are 
provided as inputs to STATE 20294's registers. A particular State register is set and provides a State Flag 

4D output when CS 101 1 0 enters the State associated with that particular register. State Rag outputs of STATE 
2Q294's state registers are provided as enable signals throughout CS 10110 to enable initiation of 
operations allowed within CS 1011 0's current State, and to inhibit initiation of operations which are not 
allowed within CS 101 10's current State. 

Certain of CS 101 10's States, and assodated STATE 20294 State Registers and State Flag outputs, are: 

4s (1) MO: the initial State of any microinstruction. 

State MO is always entered as first data cycle of every microinstruction. During MO, CS 10110*s State 
may not be changed, thus allowing a microinstruction to be arbitrarily aborted and restarted from State 
MO. In normal execution of microinstructions. State MO is followed by State Ml, described befow, that Is, 
State MO is exited to State Ml . State MO may be entered from State MO and from State Ml, State AB, State 

so LR, State NR, or State MS, each of which will be described below. 

(2) EP: Enable Pause Stata State EP is entered when State MO is entered for the first time in a 
microinstruction. If that microinstruction requests a pause, that microinstruction will force State MO to be 
re-entered for one dock cycle. If State MO lasts more than one dock cycle. State EP is entered on each 
extension of State MO unless the extension is a result of a pause request 

ss (3) SR: Source GRF State. SR State is active for one clock cyde wherein SR State register enables 

loading of a GRF 10354 output register. State SR is re-entered on every State MO cycle except a State MO 
cyde generated by a microinstruction requesting extension of State MO. When all STATE 20294 State 
Registers are cleared, DP 20218 may set state SR register alone, for purposes of reading from GRF 10354. 
(4) Ml: Rnal state of normal microinstruction execution. State Ml is the exit State of normal 

60 microinstruction execution. FUSITT 1 1 01 2 microinstruction register, described below, is loaded whh a next 
microinstruction upon exit from State Ml. In addition. State Ml Flag ouQjut of STATE 20294 enables all CS 
10110 registers to recehre data on their inputs, that is data on inputs of these registers are docked to 
outputs of these registers. State Ml may be entered from State Ml, or from State MO, Slate MW, State 
MWA, or State WB. , ^ ^ . 

^ (5) LA: Load Accumulator Enable State. State LA is entered, upon exit from State Ml, by 
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microinstructions which read data from MEM 10112 to OFFMUXR 23812. As previously described, 
OFFMUXR 23812 serves as a general purpose accumulator for DESP 20210. STATE LA overlaps into 
execution of next microinstruction, and persists until data is returned from MEM 10112 in respwse to a 
request to MEM 10112. When MEM 10112 signals data is available, by asserting DAVFA, LA State Rag 
5 -enables loading of data into OFFMUXR 23812. If the next microinstruction references OFFMUXR 23812, that 
microinstruction execution is defen-ed until a read to OFFMUXR 23812 is completed, as indicated by CS 
10110 exiting from State LA. 

(6) RW: Load GRF 10354 Wait State. State RW is entered from State Ml of microinstructions which read 
data from MEM 10112 to GRF 10354. RW Fag Inhibits initiation of a next microinstruction, that is prevents 

10 entry to State MO, and per»sts through the CS 101 10 clock cyde during which data is returned from MEM 
10112 in response to a request State RW initiates Load GRF Enable State, described below. 

(7) LR: Load GRF Enable State. State LR is entered in parallel with State RW, on last dock cyde of RW, 
and persists for of»e CS 10110 dock cycle. LR Flag enaWes vmting of MEM 10112 output data into GRF 
10354. 

w (8) MR: Memory Reference Trailer State. State MR is entered on transition to State MO whenever a 
previous microinstruction n^akes a logical or physical address references MEM 10112. MR Flag enables 
recognition of any MEM 101 12 reference Events, described below, which may occur. State MR persists for 
one dock cycle. If an MEM 101 12 memory reference Event occurs, that Event forces exit from State MR to 
States AB and MA, otherwise State MR has no effect upon selection next state. 

^0 (9) SB: Store Back Enable State. State SB is entered during State MO of a microinstruction following a 
microinstruction which generated a store back of a result of a EU 10122 operation. SB Flag gates that result 
to be written into MEM 10112 through JPD Bus 10142. 

(10) AB: Microinstruction Abort State. State AB is entered from first MO State after an Event request is 
recognized, as described in a following description. 

25 State AB may be entered from State MO or from State AB and suppresses an entry into State Ml. If 
there has been an uncompleted reference to MEM 10112, that is, the reference has trot been aborted and 
data has not returned from MEM 10112, JP 10114 remains in State AB until the MEM 10112 reference is 
completed. Should an abort have occurred due to a MEM 10112 reference Event, State AB lasts two clock 
cydes only. As will be described in a following description of EVENT 20284, State MO of a first 

30 microinstruction of a Handler for an Event causing an abort Is entered from State AB. AB Rag gates the 
Handler address of the highest priority recognized Evem onto CSADR Bus 20204 to select a corresporuling 
Event Handler mtcroinstruction sequence. EVENT 20284 is granted control of CSADR Bus 20204 during all 
State AB dock cydes. 

0 1 ) AR : Microinstruction Abort Reset State. State AR is entered in parallel with first dock cyde of State 
35 AB and persists for one dock cyde. AR Flag resets various STATE 20294 State Registers when an abort 
occurs. If there are no uncompleted MEM 10112 references, next State AB dodc cyde is the last On 
uncompleted MEM 10112 references. State AR is entered, but State AB remains active until reference Is 
complete. Should a higher priority Event request service and be recognized while JP 10114 is In State AB, 
State AR is reentered. State AB v^ll tfiereby be active for two dock cydes during all honored Event 
40 requests. 

(12) MA: MEM 10112 Reference Abort State MA is entered in parallel vifith State AB rf a MEM 101 12 
reference is aborted, as indicated by asserted ABORT control signal output from MEM 10112. State MA 
persists for one dodc cyde and State AB flag generates a MEM 10112 Reference Abort Flag which, as 
described below, results in a repeat of the MEM 101 12 reference. AB Rag also r^ets MEM 101 12 Trailer 

45 States, described below. 

(13) NW: Nano-interrupt Wait State. State NW is entered from State MO of a microinstruction which 
issues a Nano-interrupt Request to EU 10122 for an EU 10122 operation. FU 10120 remains in State NW 
until EU 10122 acknov>fledges that interrupt Various EU 10122 Events may make requests at this time. State 
NW is e)dted into State AB or State Ml. 

so (14) FM: First Microinstruction of a SIN. State FM is entered In parallel with State MO on first 
nticroinstruction of each SIN and persists for one dock cycle. FM Flag Inhibits premature use of AF 24220 
and enables recognition of SIN Entry Events. State FM is reentered upon return from all aborts taken 
during State MO of the first microinstruction of an SIN. 

(15) SOP: Original Entry to first SIN. State SOP is entered upon entry to State MO of the first 
55 microinstruction of an SOP and is exited from upon any exit from that microinstruction. State SOP is 

entered only once for eadi SOP. SOP Flag may be used, for example, for monitoring performance of JP 
10114. 

(16) EUr EU 10122 C^erand Buffer Unavailable. State EU is entered from State MO of a microin^ction 
which attempts to read data to EU 10122 Operand Buffer, described in a following description, wherein EU 

60 10122 Operand Buffer is fulL When a hew SOP is entered, three fetches of data from MEM 10112 may be 
performed before EU 10122 Operand Buffer is full; two fetches will fill EU 10122 Operand Buffer but EU 
10122 may take one operand during a second fetch, thereby dearing EU 10122 Operand Buffer space for a 
third operand. j t.. 

(17) NR: Long Pipeline Read. Entry into State NR disables overiap of MEM 10112 reads and dtsabl^ 
€s execution of the next microinstruction. A following microinstruction does not enter State MO until . 
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* requested data is returned from MEM 10112, State MR is entered from State MR or from State Ml. 

(18) NS: Nonpipellne Store Back. State NS is entered In parallel with State SB whenever a 
microinstruction requesting a pipeline store back, or a write to MEM 101 12, occurs. State NS flag generates 
entry into State MO of a following microinstruction upon exit from State SB. 
5 (19) WA: Load Control Store State A. State WA is entered from State MO of a microinstruction which 
directs loading of microinstruction Into FUSITT 11012. WA State Rag controls selection of addresses to 
CSADR Bus 20204 for writing into FUSITT 11012, and generates a write enable pulse to FUSITT 11012 to 
write microinstructions Into FUSITT 11012» 

(20) WB: Load Control Store State B. State WB is entered from State WA and is used to generate an 
fo appropriate timing Interval for wriUng into FUSITT 11012. State WB also extends State M1 to 2 clock cycles 
to ensure a valid address Input to FUSITT 11012 when a next microinstruction is to be read from FUSfTT 
11012. 

Having described certain CS 10110 states, and operations which may be performed wlthm those states. 
State sequences for certain CS 10110 operations will be described next below with aid of Rgs. 244Ato 244Z. 

15 Fig. 244A to Rg. 244Z represent those state timing sequences necessary to Indicate major features of CS 
10110 state timing. All state timing shown In Rgs. 244A to 244V assumes full pipelining of CS 10110 
operations, for example pipelining of reads from and writes to MEM 10112 by JP 10114. Rpelining is not 
assumed In Rgs. 244W to 244Z. Referring to Rgs. 244A to 244Z, these figures are drawn m the form of 
timing diagrams, with time increasing from left to right Successive horizontally positioned "boxes 

20 represents successive CS 101 10 states during successive CS 101 10 110 nano-second clock cycles. Vertically 
aligned "boxes" represent alternate CS 10110 states which may occur during a particular clock cycle. 
Horizontally extended dotted lines connecting certain states represented in Rg. 244A to 244Z represent an 
Indeterminate time Interval which is an Integral multiple of 110 nano-second CS 10110 clock cycles. 
Referring to Rg. 244A to 244Z In sequence. State Timing Sequences shown therein represent: 

2B (1 ) Rg. 244A; state timing for execution of a normal microinstruction with no Events occurring and no 
MEM 10112 references. 

<2) Rg 244B execution ol a normal microinstruction, with no Events occurring, no MEM 10112 
references, and a hold in State MO for one dock cyde. 

(3) Fig. 244C; a microinstruction requests an extension of State MO for one dock cyde, witii no Events 
30 occurring and no MEM 10112 references. 

{4) Rg. 244D; a write to MEM 101 12 from DESP 20210, for example from GRF 10354 or from OFFALU 
20242. MEM 10112 port is available and MEM 10112 reference is made during first sequential occurrence of 
States MO and Ml. 

(5) Rg, 244E; a write to MEM 10112 from DESP 20210 as described above. MEM 10112 port is 
3$ unavailable for an indeterminate number of clock cycles. A MEM 10112 reference is made during first 

sequential occurrence of States- MO and Ml. 

(6) Rg. 244F; writing of an EU 10122 result back into MEM 101 12, MEM 101 12 is availafc^e and a write 
operation is initiated during first sequential occurrence of States MO and Ml. 

(7) Rg. 244G; writing back of an EU 10122 result to MEM 10112 as described above. MEM 10112 port is 
40 unavailable for an undetermined number of clock cycles, or EU 10122 does not have a result ready to be 

written into MEM 1 01 12. Write operation is initiated during first sequential occurrence of States MO and Ml. 

(8) Rg. 244H; a read of an EU 10122 result into FU 10120. EU 10122 result Is not available for an 
undetermined number of clock cycles. 

(9) Fig. 2441; a read from MEM 10112 to OFFMUXR 23812, with no delays. The microinstruction 
^ following the microinstruction initiating a read from MEM 10112 does not reference OFFMUXR 23812. 

(10) Rg. 244J; a read from MEM 101 12 to OFFMUXR 23812 with data from MEM 10112 being delayed 
by an indeterminate number of clock cycles, the next following microinstruction from that Initiating the 
read from MEM 10112 does not reference OFFMUXR 23812. 

(11) Rg. 244K; a read from MEM 10112 to OFFMUXR 23812. The next microinstruction following the 
so rhicroinstruction Initiating the read from MEM 10112 references OFFMUXR 2381^ 

(12) Rg. 244L; a read from MEM 10112 to GRF 10354. The read to GRF 10354 is initiated by the first 
sequentially occurring States MO and Ml. 

(13) Rg. 244M; a read from MEM 10112 to GRF 10354 and to OFFMUXR 23812. In this case, read 
operations may not be overiapped. 

ss (14) Rg. 244N: JP 10114 honors an Event request and initiates a corresponding Event Handler 

microinstruction sequence, no MEM 10112 references occur. 

(15) Rg. 2440; JP 10114 honors an Event request as stated above, MEM 10112 references are made 
during the first sequential occurrence of States MO and Ml and a MEM 10112 reference Event occurs. In 
case of an MEM 1 01 1 2 reference event. State MA Is entered from one clock cycle. This occurs only if a MEM 

QQ 10112 reference is made and atwrted. 

(16) Rg. 244P; an Event occurs in a MEM 10112 reference made during tiie first sequential occurrence 
of States MO and Ml. The MEM 10112 reference does not result In a memory reference Event, CS 10110 
remains in State AB until the MEM 10112 reference is completed by return of data from MEM 10112. 

(17) Rg. 2440; a read of data ^m MEM 10112 or JPD Bus 10114 to EU 10122 Operand Queue. EU 
CS 10122 Operand Queue is not fiilL 
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{18} Fig. 244B; a read of MEM 10112 or JPO Bus 10142 data to EU 10122 Operand Queue. EU 10122 
Operand Queue is full when the microinstruction initiating the read is issued. 

(19) Rg. 244S: a request for a "nano-interrupt" to EU 10122 by FU 10120 with no Events occurring, 

(20) Rg. 244T; FU 10120 submits a "nano-interrupf request to EU 10122 and an EU 10122 State 
s Overflow^ described further in a following description, occurs. No other Events are recognized, as 

described in a following description of EVENT 20284. 

(21) Rg. 244U; FU 10120 submits a "nano-interrupt" request to EU 10122. Another Event is recognized 
during State MO and an abort results. Rrst abort state is entered for the non-EU 10122 event All aborts 
recognized in State MO are taken or acknowledged, before entrance Into State MO. Therefore, on retry at 

10 State MO of the original microinstruction entered from State MO, next abort recognized is for EU 10122 
Stack Overflow Event since EU 10122 Stack Overflow has higher priority. 

(22) Rg. 244V: a load of a 27 bit microinstruction segment into FUSITT 11012. 

In Rgs. 244A to 244V, pipelining MEM 10112 reads and writes, and of JP 10114 operations, has been 
assumed. In Hgs. 244W to 244Z, non-overiapping operation of JP 10114 is assumed. 
'5 (23) Rg. 244W; a read of data from MEM 101 12 to OFFMUXR 23812. 

(24) Rg. 244X; a read of data from MEM 10112 to EU 10122 Operand Queue. 
OS) Rg. 244Y; a wrHe of an EU 10122 result into MEM 10112. 

(26) Rg. 244Z; a read of a 32 bit SIN word from MEM 10112 in response to a prefetch or conditional 
prefetch requ^ 

20 Having described the general structure and operation of STATE 20294, and the operating states and 

operations of CS 10110, structure and operation of EVENT 20284 will be described next below. 

b.b.b. Event Logic 20284 (Figs. 245, 246, 247, 248) 
An Event is a request for a change in sequence of execution of microinstructions which is generated hy 
25 CS 101 10 drcuftry, rather than by currently executing microinstructions. Occurrence of an Event will result 
In provision of a microinstruction sequence, referred to as an Event Handler, by FUSTTT 11012 which 
modifies CS 101 Ws operations in accordance with the needs of that Event Event request signals may t>e 
generated by CS 10110 circuitry internal to JP 10114, that is from FU 10120 or EU 10122 or CS 10110 
circuitry external to JP 101 14, for example from lOP 10116 or from MEM 10112. Event request ^nals are 
30 provided as inputs to EVENT 20284. As vwll be described further below, EVENT 20284 masks Event 
Requests to determine which Events will be recognized during a particular CS 10110 Operating State, 
assigns priorities for servicing multiple Event Requests, and fabricates Handler addresses to FUSITT 1 1012 
for microinstruction sequences for servicing requests. EVEI^ 20284 then provides those Handler 
microinstruction addresses to FUSITT 1 1012 through EVNTGT 24310, to initiate execution of selected Evem 
35 Handler microinstruction sequences. 

Certain terms and expressions are used throughout the following description. The following 
paragraphs define these usages and provide examples illustrating these terms. An Event "nriakes a 
request" when a condition in CS 10110 hardware operation results in a Event Request signal Iwing 
provided to EVENT 20284. As will be described further below, these Event Request signals are provided to 
^ EVENT 20284 combinatorial logic which determines the validity of those "requests". 

An Event Request "is recognized" if It is not masked, that is inhibited from being acted upon. Ma^ng 
may be explicit using masks generated by FUSITT 11012, or may be implidt resulting from an improper 
CS 10110 State or invalid due to other considerations. That is, certain Events are recognized only during 
certain CS 10110 Stat^ even though those requests may be recognized during certain other states. Any 
number of requests, for example up to 31, may be simultaneously recognized. 

An Event Request is "honored" ff it is the highest priority Event Request occurring. When a request is 
honored, a corresponding address, of a corresponding microinstruction sequence in FUSITT 11012, for its 
Handler microinstruction sequence is gated onto CSADR Bus 20204 by EVENT 20284. A request is honored 
when CS 10110 enters State AB. State AB gates the selected Evem Handler microinstruction address on 
so CSADR Bus 20284. 

To summarize, a number of Events may request service by JP 10114. Of these Events, all, some, or 
none, may be recognized. Only one Event Request, the highest priority Event Request, will be honored 
when JP 10114 enters State AB. Microinstruction control of CS 10110 will then transfer to that Event's 
Handler microinstruction sequence. A necessary condition for entering State AB is that an Event Request 
& .has been made and recognized. 

A microinstruction sequence "completes", '1s completed", or reaches "completion" when CS 10110 
exits State Ml v^ile that microinstruction sequence is active. A microinstruction sequence may, as 
described above, be aborted in State MO an indefinite number of times before, if ever, reaching completiort 

A MEM 10112 reference "completes", ''is completed", or reaches "completion" when requested data 
eo is returned to the specified destination, that is read from MEM 10112 to the requestor, or MEM 10112 
accepts data to be written into MEM 10112. 

'Trace Traps" are an inherent feature of microinstructions being executed. Trace Traps occur on every 
microinstruction of a given type (if not masked), for example during a sequence of microinstructions to 
perform a Name evaluate or resohre, and occur on each microinstruction of the sequence. In general, a 
65 . Trace Trap Event must be serviced before execution of the next microinstruction. Trace Traps are distinct . 
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from Interrupts In that an Interrupt, described below, does not occur on execution of each microinstruction 
of a microlnstnjctlon sequence, but only on those microinstructions where certain other conditions must 
be considered. 

"Interrupts" are the largest class of events in JP 101 14. Occurrence of an Interrupt may not, in general, 
* be predicted for a particular execution of a particular microinstruction in a particular instance. Interrupts 
may require service before execution of the next microinstruction, before execution of the current 
microinstruction can complete, or before iseginning of -the next SIN. An Interrupt may be unrelated to 
execution of any microinstruction, and is serviced before beginning of the next microinstruction. 

A "IVIachine Check" is an Event that JP 10114 may not handle alone, or whose occurrence makes 
further actions by JP 10114 suspect These events are captured in EVENT 20284 Registers and result in a 
request to DP 101 18 to stop operation of JP 101 14 for subsequent harKiling. 

In summary, three major classes of Events in CS 10110 are Trace Traps, Interrupts, and Machine 
Checlcs. Each of these class of events will be descHbed in further detail below, beginning with Trace Traps. 

This State of alt possible Trace Trap Event Requests, whether requesting or not requesting, is loaded 
into EVEi^ 20284 Registers at completion of State IVI1 and at completion of State AB. That Is, since Trap 
Requests are a function of the currently executing microinstruction, the State of a Trap Request will be 
loaded into EVENT 20284 Trace Trap Registers at end of State Ml of each currently executing 
microinstruction. Similarly, if any Trap Requests are recognized, State AB vwll be entered at the end of the 
first clock cycle of the next following State MO and their State loaded at end of the State AB. 

Recognized, or unmasked. Trap Requests inay be pushed onto RCWS 10358 as Pending Requests. 
Unrecognized, or masked. Trace Trap Requests may be pushed onto RCWS 10358 as Not Pending Requests 
and are subsequently disregarded. Subsequently, when a microinstruction sequence ends In a return to a 
calling microinstruction sequence, the Trace Trap Request bits in an RtWS 10358 may be used to generate 
Trace Trap Event Requests. 

2S Upon exit from State AB, all Trace Trap Requests, except Micro-Break-Point and Microinstruction Trace 

Traps, described below, are loaded Imo corresponding EVENT 20284 Trace Trap Request Registers as not 
requesting. Micro-Break-Poim and Microinstruction Trace Traps, are, in general, always latched as 
requesting at completion of State AB. Trace Traps may be explicitly masked by a Trace Mode Mask, an 
Indivisibility Mode Mask, and by a Trace Enable input, all generated by FUSITT 1 1012 as described below. 

30 Micro-Break-Polm Trap may also be masked by clearing a Trace Enable bit in a Trace Enable field of certain 
microinstructions containing Trace Traps. In general, masking is effecth/e from State MO of the 
microinstruction which generates the mask, through completion of a microinstruction which clears the 
mask Trace Traps generated by a microinstruction which clears a mask are tatoi so as to abort a following 
microinstruction during its MO State. 

Referring to Fig. 245, CS 10110 state timing for a typical Trap Request, and generation of a 
microinstruction address to a corresponding Trace Trap Handler microinstruction sequence by EVENT 
20284 is shown. Rg. 245 is drawn using the same conventions as described above with reference to Rg. 
244A to 244Z. In Rg. 245. a microinstruction executing in States MO and Ml causes a Trace Trap Bequest 
but does not generate an MR (Memory Reference) Trailer State. Trace Trap Request to EVENT 20284 is 

<o signaled by Time A. This Trace Trap Request is latched into EVENT 20284 Trace Trap Event Registers, and 
an Abort Request is provided to STATE 20294. At Time B, FU 10120 enters States AB and AR. The 
microinstruf^on address for a Handler microinstruction sequence of the highest priority Event present in 
EVENT 20284 is presented to FUSITT 11012 and execution of the addressed microinstruction sequence 
begins. At Time C, FU 10120 exits States AB and AR and enters State AB. State AB will be exited at end of 

45 the next 110 nanosecond dock cycle. Address of the selected Event Handler microinstruction sequence will 
remain on CSADR Bus 20204 for duration of State AB, At Time D, a pointer into RCWS 10358, described in a 
following description, is incremented, thereby effectively puling the first microinstruction's return control 
word, that is the microinstruction executing at first State MO, onto RCWS 10358. First microinstruction of 
the Trace Trap Event Handier microinstruction sequence is provided by FUSITT 11012. Execution of 

60 Handler microinstruction sequence will begin at start of the third State MO of the state timing sequence 
shown in Fig. 245. EVENT 20284's Trace Trap Register for this event is now latched in nonrequesting state 
and VM'll remain so until transition out of second State M1 shown in Rg. 245. At this time, EVENT 20284 
Registers will latch new Trap Requests. Rnally, at Time E, Trace Trap Event Registers of EVENT 20284 are 
latched with new Trap Requests arising from execution of the microinstruction being executed in States MO 

55 and Ml occurring between Times D and E. Traps due to the microinstruction that was executed in States 
MO and Ml before Time A, but were not serviced, are requested again when the previously pushed RCW 
described above is returned from RCWS 10358 upon return from the Trace Trap Event Handler 
microinstruction sequence initiated at Time D. All Trace Trap Requests which have been serviced are 
explicitiy deared in RCWS 10358 RCWs by their Event Handler microinstruction sequences to prevent 

60 recurrence of tiiose Trap Requests. Since Trace Trap Event Requests arising from reads or writes to MEM 
101 1 2 will recur if those requests are repeated, EVEI^T 20284 generates memory repeat Interrupts after all 
aborted MEM 10112 read and v^te requests to insure that these Traps will eventually be serviced. Event 
Handier microinstruction sequences for these read and write Trace Trap Events explidtiy disable serviced 
Trace Trap Event Requests by clearing bits in the logical descriptor of the aborted memory read and write 

6$ requests. 
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Having described overall stnicture and operation of Trace Trap Events, certain specific Trace Trap 
Events will be described in greater detail below. Trace Trap Events occurring in CS 10112 may include 
Name Trace Traps, SOP Trace Traps, Microinstruction Trace Traps, Micro-Break-Point Trace Traps, Logical 
Write Trace Traps, Logical Read Trace Traps, UID Read Trace Traps, and UID Write Trace Traps. These 
Trace Traps will be described below In the order named.. 

A Name Trace Trap is requested upon every microinstruction sequence that contains an evaluate or 
resolve of a Name syllable. Name Trace Traps are provided by decoding certain microinstruction Itelds of 
those microinstruction sequences. Name Trace Trap field is masked by either Trace Mask, Indivisibility 
Mask* or Trace Enable, as described above. Alt of these masks are set and cleared by microinstruction 
control signals provided during microinstruction sequences calling for resolves or evaluates of Name 
syllables. 

A SOP Trace Trap may be requested whenever FU 10120 enters State FM (Rrst Microinstruction of an 
SOP). SOP Trace Traps may be masked by Trace Mask, Indivisibility Mask, or Traoe Trap Enable, again 
provided by microinstruction control outputs of FUSITT 11 01 2. In general, the first microinstruction of such 
a microinstruction sequence interrupting such SOPs is not completed before a Trace Trap is taken. 

Microinstruction Trace Traps may be requested upon completion of microinstructions which do not 
contain a Return Command, that is those microinstructions which do not return microinstruction control of 
CS 10110 to the calling microinstruction sequence. For microinstruction sequences containing Return 
Commands, state of microinstruction Trace Trap Request in a corresponding RCW is used. Every 
microinstruction for which a Microinetniction Trace Trap is not masked is aborted during State MO of 
execution of that microinstruction. Microinstruction Trace Traps may be masked t>y Trace Mask, 
IndWisibility Mask, or Trace Enable from FUSITT 11012. A M'cro-Break-Point Trap may be requested upon 
execution of microinstructions which do not contain Retum Commands, but in which a Trace Enable bit in a 
microinstruction is asserted. A Micro-Break-Point Trap may be masked by Trace Mask, indivisibility Mask, 
or Trace Enable. In addition, a Trace Enable bit of a microinstruction field in these microinstruction 
sequences controls recognition of Micro-Break-point Traps. Micro-Break-Point Traps are thereby requested 
lA^never a microinstruction Trace Trap is requested, but have additional enabling conditions expressed In 
the microinstructions. Since only recognized Traps are pushed onto RCWS 10358 in a RCW, a 
Microinstruction Trace Trap and a Micro-^eak-Point Trap havring different nsquest states may be present in 
RCWS 10358 concurrentiv. 

Logical Write Traoe Traps may be requested when enabled by a bit set in a logical descriptor during a 
microinstruction sequence submitting a write request to MEM 101 12 and using logical descriptors to do so. 
Logical Write Ttace Traps are recognized only ff they occur durirtg a state which will be imntediately 
followed by State MR (Memory Reference Trailer). A Logical Write Trace Trap will result in the MEM 101 12 
write request being aborted. Logical Write Trace Tra|:RS may be m^ed by Trace Masks, Indh/islbillty Mask, 
or Trace Trap Enable. A fiirdter condition for recognition of a Logical Write Traoe Trap is determined by the 
state of certain bats in a logical descriptor of tiie memory write request Logical Write Trace Traps are, in 
general, not pushed onto RCWS 10358 as part of a RCW since aborted MEM 10112 requests are re- 
generated so that Logical Write Trace Traps may be repeated. 

Logical Read Trace Traps are similar In all respects to the Logical Write Trace Traps, but occur during 
MEM 101 12 read requests. Generation of Logical Read Trace Traps is controlled again in part by certain bits 
in logical descriptors of MEM 10112 read requests. 

In certain implementations of CS 10110, UID Trace Traps may be requested when FU 10120 requests an 
MEM 10112 read operation based upon a UID address or pointer. UID Read Trace Traps are recognized if 
requeued and there is, in general, no explicit masking of UID Read Trace Traps. Generation of UID Read 
Trace Traps is controlled by certain bits in MEM 10112 read request logical descriptors. UID Read Trace 
Trap Requests r^ult in the MEM 10112 read requests being aborted and CS 10110 entering State AB. 
Handler microinstruction sequences for UID Read Trace Traps will, in general, reset the trapped enable bit 
in the MEM 10112 read request logical descriptor before re-issuing the MEM 10112 read request 

UID Write Trace Traps are similar to UID Read Trace Traps, and are corrtrolled by bits in the logical 
descriptor in MEM 10112 write request based upon UID addresses or pointers. 

Having desaibed above structure and operation of Trace Trap Events, CS 10110 Interrupt Events will 
be described next below. 

As previously described, Interrupts form the largest class of CS 10110 Events. Interrupts may be 
regarded as falling into one or more of several classes. Rrst, Memory Reference Repeat Interrupts are those 
Interrupt Events associated, in general, with read and write requests to MEM 101 12 in which a read or write 
request is submitted to MEM 101 12, and an Interrupt Event results. That Interrupt Event is handled, and the 
MEM 10112 request repeated. Second, Deferred Service Interrupts are those Interrupts wherein CS 10110 
defers service of an Interrupt until entry to a new SIN. Fourth, Microinstruction Service Interrupts occur 
when a currentiy executing microinstruction requires assistance of an Event Handler microinstruction 
sequence to be completed. Rnally, Asynchronous Interrupt Events may occur at any time and must be 
sen/iced before CS 10110 may exit State MO of the next microinstruction. These Interrupt Events will be 
described next below in the order named. 

A Memory Reference Repeat Internipt is requested, for example, if a microinstmction executes a 
command, and a corresponding RCW read from RCWS 10358 indicates that a memory reference was 
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aborted before entrance to the microinstruction ^uence from which return was executed. This type of 
Interrupt Event occurs for ell aborted memory references. If an event is honored, that is abort state is 
entered, for any event and there is a memory reference outstanding, not aborted, the memory retef"f Jjce- 
completes before State AB Js exited. No memory Repeat Interrupt Request will be written mto the RCW 

s written onto RCWS 10358. Conversely, if a memory reference is aborted, even if the event honored is not 
that event which aborted the memory reference, a Memory Repeat Interrupt Request will be written into a 
RCW pushed onto a RCWS 10358. , i . ♦u^.^ 

There are two state timing sequences for execution of Memory Repeat Interrupts. In the first case, there 
are no MEM 10112 references In the mcroinstruction executing a Return Command. In the second case, a 

w microinstruction executing a Return Command executes a return end also makes a MEM 1 01 12 reference. 
Referring to Fig. 246, a CS 10110 State Timing Diagram for the first case is shown. Fig. 246 is drawn usmg 
the same conventions as used in Fig. 244 and 245. As described above, in the first case a J^^tion 
executing a Retum Command is executed in States MO and Ml following Time D. An aborted MEM 10112 
reference was made in States MO and Ml preceding Time A. An MEM 10112 Reference Abort Request is 

IS made upon CS 101 lO's entiy into State MR following Time A, Since a Memory Repeat interrupt is requested 
only from a RCW provided by RCWS 10358, a Memory Repeat Interrupt is indicated only if a 
microinstruction executes a Return Command resulting in RCWS 10358 providing such an RCW. Therefore, 
a Memory Repeat Interrupt Request Register of EVENT 20284 is loaded with "not requesting at this time. 
At Time B, CS 10110 enters State AB, State AR, and State MA. At this time, a Memory Reference Abort 

20 Request Is asserted and written Into an RCW vi^en State AB is exited just before Time D. At lime a CS 
101 10 exits State AR and Stete MA. As just described, CS 101 10 will remain in State B until Time D. At Time 
D, Memory Reference Abort Request is written Into RCWS 103S8 as part of an RCW a^^l, as d^^^^^ 
further below, various RCWS 10358 Steck Pointers are incremented to load that RCW into RCWS 10358. At 
this time, EVEISTT 20284's Imerrupt Request Register receives "no request" as state of Memory Repeat 

25 Interrupt. First microinstruction of Memory Repeat Interrupt Handler miaofnstruction sequence is provided 
by FUSITT 11012. At Time E, ttie last microinstruction of the Memory Repeat ^"^^rmpt Handler 
microinstruction sequence is provided by FUSrmi012 and a Retum Command is decoded. RCWS 10358 
Previous Stack Pointer, previously described. Is selected to address RCWS 10358 to provide the Previoush^ 
written RCW as output to EVENT 20284's Memory Repeat Intemjpt Event Register. At Time F, EVENT 

so 20284's Memory Repeat Interrupt Register is loaded from output of RCWS 10358 and RCWS tO^s ^ack 
Rfegister Pointers are decremented. At ^is time. Memory Repeat Intenrupt Request is "[lade and, as 
described beiow, is written into the current Retum Control Word, whether honored or not JP 10114 then 
repeats the abortwl MEM 10112 reference. ^ ^. ^ , 

In the second case, a State Timing Sequence wherein the microinstruc^on ««^"9 « ri^J^ 

35 makes a MEM 10112 reference, CS 10110 State Timing is identical up to Time F. At Time F, MEM 10112 
Repeat request is not recognized and the stete of Memory Repeat Interrupt written Into the current Return 
Control Word is ' not requesting" unless a current MEM 10112 reference is aborted. The previous MEM 
1 01 12 Repeat Interrupt Request is disregarded as it is assumed that it is no longer required. Thus, there are 
two ways to avoid, or cancel a Memory Repeat Interrupt Request First, that portion of a RCW '^ceiving a 

40 MEM 10112 Repeat Interrupt Request may be rewritten as "not requesting". Second, an aborted MEM 
10112 reference may be made in the same microinstruction that returns from a Handler servicing the 
aborted MEM 10112 reference. , ^ t 

Certain CS 10110 Events result in aborting a MEM 10112 read or wnte references and may result in 
repeat of MEM 10112 references. These events may include: ^ ^ t 

45 (1) Logical read and write Traps and. In certain Implementations of CS 101 10, UID read and write Traps, 

previously discussed; 
{21 A PC 10234 miss; 

(3) Detection of a protection Violation by PC 10234; 

(4) A Page Crossing in a MEM 10112 read or write request; 

50 (5) A Long Address Translation, that is an ATU 10228 miss requiring JP 10114 to evaluate a logical 

descriptor to provide a corresponding physical descriptor; 

(6) Detection of a reset dirty bit flag from ATU 10228 upon a MEM 10112 write request as previously 

described; 

(7) An FU 10122 steck overflow; 
ss (8) An FU 10122 Illegal Dispatch; 

(9) A Name Trace Trap event as previously described; 

(10) A Store Back Exception, as will be desmbed below; 

(1 1 ) EU 101 22 Evente resulting in aborting of a Store Back, that is a write request to MEM 101 1 2 from 

EU 10122; « . • f^MHKn 

60 (12) A read request to a non-accelerated Stack Frame, that is a Steck Frame presently residing in MEM 

10112 rather than accelerated to JP 101 14 Steck Mechanisms; and, 

(13) CondHional Branches in SIN sequences resulting outstanding MEM 10112 read reference from 

^'^^f 5S liSite, Logical Read ahd Write Traps. UID Read and Write Traps, and Name Trace Traps have 
65 been previously described. Other Evente listed above will be described next below m further detail. 
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A PC 10234 Miss Interrupt may be requested upon a logical MEM 10112 reference, that is when a 
logical descriptor is provided as input to ATU 10228 and a protection state is not encached in PC 10234. PC 
10234 will, as previously described, indicate that a corresponding PC 10234 entry is not present by 
providing a Event Protection Violation (EVENTFVIOL) output to EVENT 20284. PC 10234 will concurrently 
5 assert an Abort output (ABORT) to force CS 101 10 into State AB and thus abort that MEM 101 12 reference. 
A Page Crossing MEM 10112 Reference Interrupt Is requested if a logical MEM 10112 reference, that is 
a logical descriptor, specifies an operand residing on two logical pages of MEM 10112. An output of ATU 
10228 will abort such MEM 10112 references by asserting an Abort output (ABORT). 

A Protection Violation Interrupt Is requested if a iogicai MEM 10112 reference does r)Ot possess proper 
w access rights, a mode violation, or if that reference appears to refer to an illegal portion of that object an 
e3ctent violation. Again, PC 10234 will Indicate occurrence of a Protection Violation Event, which may be 
disabled by a microinstruction control output of FUSfTT 11012. 

A Long Address Translation Event may be requested upon a logical MEM 10112 reference for which 
ATU 10228 does not have an encached entry. ATU 10228 will abort that MEM 101 12 reference by asserting 
IS outputs ABORT and Long Address Translation Event (EVENTLAT). 

A Dirty Bit Reset Event Intentipt may be requested when JP 101 14 attempts to write to an MEM 10112 
page having an encached entry in ATU 10226 whose dirty bit is not set. ATU 10228 will abort that MEM 
1 01 1 2 write request by asserting outputs ABORT and Write Long Address Translation Event (EVENTWLAT). 
. An FU 10120 User Stack Overflow Event may be requested ff the distance between a Current Frame 
20 Pointer and a Bottom Frame Pointer, previously described with reference to CS 101 10 Stack Mechanisms, is 
greater than a gh^en value. As previously d^cribed, in CS 10110 this value is eight. A User Stack Overflow 
Event will continue to be requested until either Current Frame Pointer or Bottom Frame Pointer changes 
value so that the differ^ice limit defined above is no longer violated. A User Stack Overflow Event may be 
masked by a Trace Ma^ an Indivisibility Mask, or by enable outputs of a microinstruction from FUSITT 
25 1 1 01 2. A Handler mlcroinsmictkm sequence for User Stack Overflow Events must be executed with one or 
more of these masks set to prevent recursion of these events. CS 101 10 is defined to be running on Monitor 
Stack (MOS) 10370 when User Stack Overflow Events are masked. User Stack Overflow Events are not 
loaded into any of EVENT 20284's Event Registers, nor are these events written into a RCW to be written 
onto RCWS 10358. 

30 Illegal EU 10122 Di^tch Evwts are requested by EUSDT 20266 if FU 10120 attempts to dispatch, or 
provide an initial microinstruction sequence address, to EU 10122 to a EUSITT address which is not 
accessabte to a user's program. Illegal EU 10122 Dispatch Events are, in general, not masked. Illegal EU 
10122 C^'spatch Event Requests are cleared upon CS 10110 exits from State AB. The Handler 
microinstruction sequence for Illegal EU 10122 Dispatch Events should, in general, reset Illegal EU 10122 

55 Dispatch Event entries in RCWs to prevent recursion of these ev^ts. 

EU 10122 will indicate a Store Back Exception Event if any one of a number of exceptional conditions 
arise during arithmetic operations. These events are recognirod when CS 10110 enters State SB and are 
ignored except during Store Back to MEM 10112 of EU 10122 results. These Events may be disabled by 
microinstruction output of FUSITT 1 1012 but are, in general, not masked. Store Back Exception Events may 

40 be written into RCWs, to be stored in RCWS 10358, and are cleared upon CS 10110's exit from State AB. 
Again, a Store Back Exception Event Handler microinstruction sequence should reset Store Back Exception 
Events written into RCWs to prevent recursion of these events. 

As desaibed above, the next major dass of Interrupt Events are Deferred Service Interrupts, CS 101 10 
defers service of Deferred Service Interrupts until entry of a new SOP Deferred Sen/ice Interrupts whi<^ 

45 have been recognized will be serviced before completion of execution of the first microinstruction of that 
new SOP. Deferred Service Interrupts include Nonfatal MEM 10112 Enrors, Interval Timer Overflows, and 
Interrupts from lOS 101 16. These Interrupts will be described below, in the order named. 

A Nonfatal MEM 10112 Interrupt is signaled by MEM 10112 upon occurrence of a correctable (single 
bit) MEM 10112 error. Nonfatal Memory Error Interrupts are recognized only during State MO of the first 

50 microinstruction of an SOP. MEM 10112 will continue to assert Nonfatal Memory Error Interrupt until JP 
10114 issues an acknowledgement to read MEM 101 12^8 Error Log. 

An Interval Timer Overflow Interrupt is indicated by TIMERS 20296 when, as described below, an 
Interval Timer increments to zero, thus indicating lapse of an allowed time limit for execution of an 
operation. Interval Timer Overflow Interrupts are recognized during State MO of the first microinstruction of 

55 a SOP. TIMERS 202^ will continue to request such Interrupts until cleared by a micrcnnstruction output of 

Fusmr 11012. 

lOS 10116 will indicate an lOS 10116 Interrupt to indicate that an inter-processor message fix>m lOS 
10116 to JP 10114 is pending. lOS 101 16 will continue to assert an lOS 10116 Interrupt Requ^t which is 
stored in a register, until cleared by a microinstruction control output of FUSITT 1 1012. lOS 101 16 interrupts 
€0 are recognized during State MO of the first microinstruction of an SOP. 

The next major class of CS 10110 events are Interrupts due to the requirement by mii^oinstruction 
sequences to be serviced in order to complete execution. These Interrupts must be serviced before a 
microinstruction sequence may be completed. Microinstruction Service Interrupts include Illegal SOP 
Events, Microinstructions Not Present in FUSITT 1 1012 Events, an attempted parse of a hung INSTB 20262, 
es underflow of an FU 10120 Stact an NC 10226 Cache Miss, or an EU 10122 Stack Overflow. Each of these 
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events will be described below, in the order named. j • i o j 

An Illegal SOP Event is indicated by FUSDT 11010 to indicate that a current SOP Code is a Long Code, 
that is greater than eight bits; while the current dialect (S-Language) expects only Short Operation Codes, 
that is eight bit SOPs. An Illegal SOP Interrupt is not detected for unimplemented SOPs within the proper 
code length range. Illegal SOP Events are, in general, not masked. FUSDT 11010 continues to indicate an 
Illegal SOP Event until a new SOP is loaded Into OPCODEREG 202^. Illegal SOP Events are recognized 
during the first microinstruction of an SOP, that Is during State FM. Should a Handler microinstii^^^ 
sequence for a higher priority event change contents of OPCODEREG 20268, a previous Illegal SOP Event 
will be indicated again when the aborted SOP is retried. 

/^nce of a Microinstruction in FUSITT 1 1012 is indicated by FUSITT 11012 asserting a Control Store 
Address Invalid (CSADVAUD). This FUSITT 11012 output Indicates that that particular microinstmction 
address points outside of FUSITT 11012's address space. Output of FUSITT 11012 in such event is not 
determined and parity checking, described below, of microinstruction output is inhibited. The Handler 
microinstruction sequence for these Events will load FUSITT 11012 address zero vwth the required 
microinstruction from MEM 10112, as previously described, and return to the original microinstruction 
sequence. 

An attempted paise of a hung INSTB 20262 is indicated by INSTBWC 24110 when a parse operation is 
attempted, INSTB 20262 is empty, and PREF 20260 is not curfently requesting SINs from IWIEM 10112. In 
general, these Events are not masked. If a higher priority Event Is servicec^ these Events are indicated again 

^ when the aborted microinstniction is retried if the original conditions stiil apply. 

An l=U 10120 Stack Und^ow Event is requested when a current microinstruction references a 
Previous Stack Frame which is not in an accelerated stack, that is, the Current Stack Pointer equals Bottoin 
Stack Pointer. FU 10120 Underflow Events are, In general, not masked and are requested again on a retry » 
the microinstruction Is aborted and this event has not been serviced. 

2s An NC 10226 Miss Interrupt occurs on a MEM 10112 read or write operation when a load or read of NC 
1 0226 is attempted and there is no valid NC 10226 Mock corresponding to that Name syllable. An NC 1 0226 
IWiss Event does not resuH in a request for a Name evaluate or resolve. In general, these Events are no* 
' masked and result in a request being issued again if the microinstruction resulting in that Event is retried 
and has not been servk»d. . \u 

» An EU 10122 Stack Overflow Event is requested from EU 10122 to Indicate that tOl^recunner^^ 
alre^ servidng m least one level of imerrupt an FU 1 0122 Is requ«tlnga^^ 

following description of EU 10122. EU 10122 contains a one level deep stack for handUng of >i^"«Pt?;f" 
wSck^^ow Events a.^ enabled during State NW. All previousfy Penf"|««^J^^ 
serviced before EU 10122 Stack Overflow Event requests are reoognfed- 3^^,"^ 
« immediately upon entry Into a following State MO. b«ng the highest pnonty Interrupt event 101^ 
Stedf 3(W Eventsfnay, in general, ?K>t be masked and once recognized are the next honored event. 

RnaHy th^ *irtl ma? dais of OS 10110 Intenupt Events are Asychronous Evente. Asynchronous 
EveSu'^ingeneral.tL serviced before ex-rting State MO ofam 

Lychronou; E^nts include Fatal Memory Error Events, AC Power Failure Evente Egg mterO^rt*^ 
« Events, and EU 10122 Stack Underflow Events. OS 101 10 Egg Timer is a part ofTIMERS 2l^6and will be 
discus^d as part of TIMERS 20296. These events will be described below, \n ^^'Si^'"^'^}^-^ 

Fatal MEM 10112 Error Events are requested by MEM 10112 by assertion of ""^l ^Ifl™' 
PMODI. previously described, when last data read from MEM 10112 contains a •;o"??J'^«l^r 
MEM 10112 Error Events are recognized on first State MO after occurrence. ^EM 10112 
■« Tre stored In an EVENT 20284 Event Register and are cleared upon entry into its service microinstruction 
sequence. In general. Fatal MEM 10112 Error Events may not be rnasked. .^a a,i np 

AC Power Failure Events are indicated by DP 10118 by assertion of (Hrtput siB^a' ^CFAWL when DP 
10118 detects a failure of power to CS 10110. Recognition of AC Power Failure Events is disablediipon 
entry tO^O^ Failure Event Handler microinstruction sequence. No further AC Power Failure Events 
50 will be racoonized until DP 10118 reinitiates JP 10114 operation. e t- 

S ^^bS^ribed further below, FUCTL 20214's Egg Timer is a part of TIMERS 20296. Egg Timer 
OverffoTEvents are Indicated by TIMERS 20296 whenever TIMERS 20296-8 Egg Tirner ^'^^^^^^J^^'^ 
ofEofl^mer Counter. Egg Timer Overflow Events may be masked as descnbed in a following description. 
R,2rE?S Underflow Events are signaled by EU 10122 when «L«f » read a word fr^^^ 
« EU 101K Steele Mechanism and there is no accelerated steck frame preseirt. EU 'I^^^^^J'""!. »° 
assert *l6^t Interrupt until acknowledged by JP 10114 by Initiation of a Handler microinstruction 

''"'"■Kbove descriptions of CS 10110 events have steted that recognition of certain ?^«hose Events m^^ 
be masked, that is inhibited to allow rwognrtion of otiier Events having h'ghe^"^'^- ^^-J^"! J 
» masking oi^rations were briefly described in the above descnptions and will be described in ft^rth«^de«8n 
- ^Tbelorin general, recognition of Evente may be masked in five ways, "^J'i'/.'^r^^^P?^^^ 
de^gnated as masks. These four masks aio generated by microinstruction control f^*" ^USnT mi2 and 
include Asychronous Masks for. in general, Asychronous Events. Monitor ^^^^ * ««n« 

01 10 opeVations being perfomied on Monitor Stedc (MOS» 10370, as previously «^^«f ^^^Xf^MaS 
65 to CS 101 10 SteckMecSanisms. Trace Mask is utilized with reference to Trace Trap Events. Indivisible Mask 
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is generated or provided by FUSITT 1 1012 as an Integral or indivisible part of certain microinstructions and 
allow recognition of certain selected events during certain single microinstructions. Certain other Events, 
for example Logical Read and Write Traps and UID Read and Write Traps, are recognized or masked by flag 
bits in logical d^criptors associated with those operations. Rnally. certain microinstructions result in 

^ FUSITT 11012 providing microinstruction control outputs enabling or inhibiting recognition of certain 
events, but differ from Indivisible Masks in not being associated with single particular microinstructions. 

Referring to Fig. 247, the relative priority level and applicable masks of certain CS 10110 Events are 
depicted therein in three vertical columns. Information regarding priority and masking of particular Events 
is shown in horizontal entries, each comprising an entry in each of these three vertical columns. Left hand 
column^ titled Priority Level states relative priority of each Event entry. Second column, titled EVENT, 
specifies which Event is referred to in that table entry. A particular Event will yield priority to all higher 
priority Events and will take presidence over all lower priority Events. Rg. 247's third column, titled Masked 
By, sptecrfies for each entry vi^ich masks may be used to mask the corresponding Event A indicates use of 
Asychronous Masks. M use of Monitor Maskr T use of Traoe Trap Mask, and I represents that Indivisible 
Mask may be used. DES indicates that an Event is enabled or masked by flag bits of logical descriptors, 
while MCWD indicates that a particular Event may be masked by microinstruction control signal outputs 
provided by FUSITT 11012. NONE indicates that a particular Event may. In general, not be masked. 

The final major class of CS 10110 evem was described above as Machine Check Ev^ts. In general, if 
any of these Events are detected by logic gating in EVENT 20284, EVENT 20284 will provide a Check 
Machine signal to DP 10118. DP 10118 will then stop operation of JP 10114 and Machine Check Event 
Handler microinstruction sequences will be initiated. Among these Machine Check Events are wherein FU 
10120 is attemting to store back an EU 10122 result to MEM 10112 and £U 10122 signals a parity error in EU 
10122's Control Stora These events are stored in EVENT 20284 Event Registers and recogized when FU 
10120 enters State AB. EU 10122 will have previously ceased operation until a corrective microinstruction 

^ sequence may be initiated. The same Event will occur if FU 10120 attempts to use an EU 10122 arithmetic 
operation result or test operation result having a parity error in EU 10122'$ Control Store. Should MOS 
10370 overflow or underflow, this event will be dete<^ed, FU 10120 operations stopped, and corrective 
microinstruction sequences initiated. MOS 10370 overflow or underflow occurs whenever a previous MOS 
10370 Stack Frame is referenced, whenever MOS 10370 Stack Pointer equals MOS 10370 Bottom Stadc 
Pointer, or the difference between MOS 10370 Currem and Bottom Stack Pointers is greater than sixteen. 
Underflows result In a transfer of operation to MIS 10368, while overflows are handled by DP 101 18. Finally, 
a Machine Check Event will be requested when a parity error is d^ected in a microinstruction currently 
being provided by FUSITT 11012 during State MO of that microinstruction. 

Having described general operation of EVENT 20284, the structure and operation of EVENT 20284 will 

^ be described briefly next below. 

Referring to Rg, 248, a partial block diagram of EVENT 20284 is shown. EVENT 20284 Includes Event 
Detector (EOET) 24810, Event Mask and Register Circuitry (EMR) 24812, and Event Handler Selection Logic 
(EHS) 24814. EDET 24810 is comprised of random logic gating and, as previously described, receives inputs 
representing event conditions from other portions of CS 1 01 10's circuitry. EDET 24810 detects occurrences 

^ of CS 101 10 operating conditions indicating that Events have occurred and provides outputs to EMR 24812 
indicating what Events are requested. 

EMR 24812 includes a set of registers, for example SN74S194S, comprising EVENT 20284's Event 
Registers. These registers are enabled by mask Inputs, described momentarily, to enable masking of those 
Events which are latched in EVENT 20284's Event Registers. Certain Events, as previously described, are 

^ not latched and logic gating having mask enable inputs is provided to enable masking of those events 
which are not latched. EMR 24812 mask inputs are Asychronous, Monitor, Trace Trap, and Indivisible 
Masks, respectively AMSIC MMSK, TMSK, and ISMK, provided from FUSITT 11012. Mask Inputs derived 
from FUSITT 11012 microinstruction outputs {mWRD} are provided from microinstruction oontrol outputs 
of FUSnr 1101Z EMR 248I2 provides outputs representing mask and unmask events which have been 

so requested to EHS 24814. 

EHS 24814 is comprised of logic gating detecting which of EHS 24814's unmasked Event Requests is of 
highest priority. EHS 24814 selects the highest priority unmasked Event Request input and provides a 
corresponding Event Handler microinstruction address to EVNTGT 24310 through ADRA Bus 24322. These 
address outputs of EHS 24814 are five bit addresses selecting the initial microinstruction of the Event 

55 Handler microinstruction sequence of the current highest priority unmasked Event. As previously 
described with reference to NASMUX 24312, certain inputs of ENTGT 2431 0 are hard-wired to provide a full 
fifteen bit addr^ output from EVNTGT 24310. EVENT 20284 also provides, from EHS 24814, an Event 
Enable Select (EES) output to SITTNAS 20^ to enable EVNTGT 24310 to provide microinstruction 
addresses to CSADR Bus 20204 when EVENT 20284 must provide a microinstruction address for handling 

60 of a current Event. 

Having described the structure and operation of FUCTL 20214's drcuitry providing microinstruction 
addresses to FUSITT 11012, FUSITT 11012 vi^ll be d^ribed next below. 

C.C.& Fetch Unit S-lnterpreter Table 11012 (Rg. 249) 
& Referring to Bg. 249, a partial block diagram of pUSITT 11012 is shown. Address (ADR) and Data 
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(DATA) inputs of Micro-lnstruclion Control Store (mCS) 24910 are connected, respectively, from CSADR 
Bus 20204 through Address Driver (ADRDRV> 24912 and from JPD Bus 10142 through Data Driver (DDRV) 
24194. mCS 24910 comprises a memory for storing sequences of microinstructions currently being utilized 
by CS 101 10. mCS 24910 Is an 8K (8192) word by 80 bit wide memory. That is, mCS 24910 may contain, for 

5 example, up to, 8192 80 bit wide microinstructions. Microinstructions to be written into mCS 24910 are 
provided, as previously described, to mCS 24910 DATA input from JPD Bus 10142 through DDRV 24914. 
Addresses of microinstructions to be written into or read from mCS 24910 are provided to mCS 24910 ADR 
input from CSADR Bus 20204 through ADRDRV 24912. ADRDRV 24912 and DDRV 24914 are buffer drivers 
comprised, for example, of SN74S240s and SN74S2448. 

to Also connected from output of ADRDRV 24912 is Input of IMonpresent Micro-Instruction Lx>gic (NPmIS) 
24916. NPmIS 2491 6 is comprised of logic gating monitoring read addresses provided to mCS 24910, When 
a microinstruction read address present on CSADR Bus 20204 refers to an address location not within mCS 
24910*5 address space, that is of a non-present microinstruction, NPmIS 2491 6 generates an Event Request 
output Indicating this occurrence. As previously described FUCTL 20214 will then call, and execute, 

IS ' microinstructions so addressed from MEM 10112. 

As indicated in Fig. 249, mCS 24910 provides three sets of outputs. These outputs are Direct Output 
(DO), Direct Decoded Output (DDO), and Butfered Decode Output (BDO). In general, control information 
within a particular microstruction word is used on next clock cycle after the address of that particular 
microinstruction word has been provided to mCS 24910 ADR input That is, during a first clock cycle a 

20 microinstruction's address is provided to mCS 24810 ADR input That selected microinstruction appears 
upon mCS 24910's DO, DDO, BDO outputs during that clock cycle and are used, after decoding, during next 
clock cycle. Outputs DO, DDO, BDO differ in delay time before decoded microinstruction outputs are 
available for use. ^ , , 

mCS 24910 DO output provides certain bits of microinstruction words directly to particular 

25 destinations, or users, through Direct Output Buffer (DOB) 24918. These microinstructions bits are latched 
and decoded at their destinations as required. DOB 24918 may be comprised, for example, of SN74S04s. 

mCS 24910'8 DDO output provides decoded microinstruction control outputs for ftinctions requiring 
the presence of fully decoded control signals at the start of the dock cycle In which those decoded control 
signals are utilized. As shown In Rg. 249, mCS 2491 0*8 DDO output is connected to input of Direct Decode 

30 Logic (DDL) 24920. DDL 24920 Is comprised of logic gating for decoding certain microinstruction word bits 
during same clock cycle In which those bits are provided by mCS 24910's DDO. These microinstruction bits 
are provided, as described above, during the same dock cycle In whidn a corresponding address is 
prwided to mCS 24910's ADR input During this dock cyde, DDL 24920 decodes mCS 24910's DDO 
microinstruction bits to provide fully decoded outputs by end of this dock cyde. Outputs of DDL 24920 are 

50 connected to Inputs of Direct Decode Register (DDR) 24922. DDR 24922 is a register comprised, for 
example, of SN74S374s. DDL 24920's fully decoded outputs are toaded into DDR 24922 at the end of tiie 
dock cyde during which, as just described, an address is provided to mCS 24910's ADR Input and mCS 
24910's corresponding DDO output is decoded by DDL 24920. Fully decoded microinstruction control 
outputs corresponding to mCS 2491 0's DDO outputs are thereby available at start of the second dock cyde. 

40 Microinstruction control outputs of DDR 24922 are theretiy available to FU 1 0120 at start of the second dock 
cyde for those FU 10120 operations requiring immediate, that is undelayed, microinstruction control signal 
outputs from FUSim 1012. , , . 

Finally, mCS 24910's BDO is provided for those FU 10120 operations not requiring microinstruction 
control dgnals immediately at the start of the second dock cyde. As shown in Rg. 249, mCS 24910's BDO Is 

45 connected to inputs of Buffered Decode Register (BDR) 24924. Microinstruction word output bits from roCS 
24910's BDO are provided to inputs of BDR 24924 during the clock cyde in which a corresponding address 
is provided to mCS 2491 0's ADR input mCS 24910's BDO outputs are loaded into BDR 24924 at end of this 
clock cyde. BDR 24924's outputs are connected to inputs of Buffered Decode Logk; <BDL) 24926. BDL 24926 
is comprised of logic gating for decoding outputs of BDR 24924. BDL 24926 thereby provides decoded 

so microinstruction control outputs to FU 10120 at some delayed time after start of the second clock cyde. 
Microinstnjction control outputs from BDL 24926 are thereby delayed in time from the appearance of 
microinstruction control outputs of DDR 24922 but as BDR 24S24 stores microinstruction word bits rather 
than decoded microinstruction word bits, BDR 24924 is required to store proportionately fewer bits than 
DDR 24922. ^ , 

ss Finally, as shown in Fig. 249 outputs of DDR 24922 and BDR 24824, are connected to Inputs of 
Microinstruction Word Parity Checker (mWPC) 24928. mWPC 24928 is comprised of logic gating for 
checking parity of outputs of DDR 24922 and BDR 24924. A failure in parity of either output of DDR 24922 
and BDR 24924 indicates a possible error In microinstruction output from mCS 24910. When such an error 
is detected by mWPC 24928, mWPC 24928 generates a corresponding MIcroinstrucdon Word Parity Error 

60 (mWPE). 

d.d. CS 10110 Intemal Mechanism Control 
Associated with SH'b 10362, the stack mechanism area of GRF 10354, are two CS 10110 control 
structures primarily assodated with operation of CS 10110's internal mechanisms. A first of these referred 
6S to as Machine Control Block, describes current execution environment of JP 10114 microprograms, that iSi 
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JP 10114 microinstruction sequences. Machine Control Block is comprised of two information words 
residing in MCWl 20290 and MCWO 20292. These Machine Control Words contain ail control state 
information necessary to execute JP 10114's current microprogram. Second control structure is a portion 
of RCWS 10358, YAxich as previously described parallels the structure of SR's 10362. Each register frame on 
^ MIS 10368 or MOS 10370 has, with exception of Top (Current) Register Frame, associated with *rt a Return 
Control Word <RCW) residing in RCWS 10358. RCWs are created when MIS 10362 or MOS 10370 register 
frames are pushed, that is moved onto MIS 10368 or MOS 10370 due to creation of a new Current Register 
Frame. A current RCW does not exist in a present embodiment of CS 10110. 

RCWS 10358 will be described first next below, followed by Machine Control Block. 

10 

a.a-a. Return Control Word Stack 10358 {Fig. 251} 
Referring to Rg. 251, a diagramic representation of a RCWS 10358 RCW is shovwi. As previously 
described, RCWS 10358 RCWs contain information necessary to reinitiate or continue execution of a 
microinstruction sequence if execution of that sequence has been discontinued. 

. Execution of a microinstruction sequence may be discontinued due to a requirement to service a CS 
10110 Evem, as described above, or If that microinstruction sequence has called for execution of another 
microinstruction sequence, as in a Branch or Case Operation. 

As shown in Fig. 251, each RCW may contain, for example, 32 bits of information. RCW Bits 16 to 31 
Inclusive are primarily conoemed with storing current microinstruction address of microinstruction 
^ sequences which have been discontinued, as described above. Bits 17 to 31 inclu^ve contain 
microinstruction sequence return address. Return address Is, as previously descrfbed, address of the 
microinstruction currently being executed of a microinstniction sequence whose execution has been 
discontinued. When JP 10114 returns from servicing of an Event or execution of a called microinstruction 
sequence, return address is provided from RCWS 10358 to SITTNAS 20286 and through CSADR Bus 20204 
^ to FUSrrr 1 1 012 as next microinstniction address to resume execution of that microinstruction sequence. 
Bit 1 6 of an RCW contains a state bit indicating whether the particular microinstruction referred to by return 
address field Is the first microinstruction of a particular SOP. That is. Bit 1 6 of an RCW stores CS 101 10 State 

Bits 8 to 15 inclusive of an RCW contain information pertaintr^ to current condition code of JP 10114 

30 and to pending Interrupt Requests. In particular. Bit 8 contains a condition code bit which, as previously 
described indicates whether a particular test condition has been met. RCW Bit 8 is thereby, as previously 
describe, a means by which JP 10114 may pass results of a particular test from one microinstruction 
sequence to another Bits 9 to 15 inclush^e of an RCW contain information regarding currentiy pending 
Interrupts. These interrupts have been previously discussed^ in general, with reference to EVENT 20284. In 

^ particular, RCW Bit 9 contains pending state of illegal EU 10122 Dispatch interrupt Requests; RCW Bit 10 
contains pending state of Name Trace Trap Request; RCW Bit 11 contains pending state of Store Back 
Interrupt Request; RCW Bit 12 cont^'ns pending state of Memory Repeat Interrupt Request; RCW Bit 13 
contains pending state of SOP Trace Trap Request; RCW Bit 14 contains pending state of Microtrace Trap 
Request; and, RCW Bit 15 contains pending state of Micro-Break Point Trap Request. Interrupt Handling 

40 microinstruction sequence whidi require use of CS 10110 mechanisms containing information regarding 
pending Interrupts must, in general, save and store that information. This save and restore operation is 
accomplished by use of Bits 9 to 15 of RCWS 10358's RCWs. Upon entry to an Interrupt Handling 
microinstruction sequence, these bit flags are set to indicate Interrupts which were outstanding at time of 
entry to that microinstruction sequence. Because these bits are used to initiate Interrupt Request upon 

45 returns, pending Interrupts may be cancelled by resetting appropriate bits of Bits 9 to 15 upon return. This 
capability may be used to implement Microinstruction Trace Traps, previously described. 

As Indicated in Rg. 251 , RCW Bits 0 to 7 are not utilized in a present embodiment of CS 101 10. RCW bits 
0 to 7 are not implemented in a present embodiment of CS 10110 but are reserved for future use. 

As previously described, RCWs may be written into or read from RCWS 10358 from JPD Bus 10142. 

so This allows contents of RCWS 10358 to be initially written as desired, or read from RCWS 10358 to MEM 
10112 and subsequently restored as required for swapping of processes in CS 10110. 

b.b.b. Machine Control Block (Rg. 252) 
As described above, FUCTL 2021 4's Madiine Control Block is comprised of a Machine Control Word 1 
55 {MCWl ) and a Machine Control Word 0 (MCWO). MCWl and MCWO reside, respectively, in Registers MCWl 
20290 end MCWO 20292. MCWl and MCWO described the current execution environment of FUCTL 20214's 
current microprogram, that is the microinstniction s^uence currently being executed by JP 10114* 

Referring to Rg. 252. diagramic representations of MCWO and MCWl are shown. As indicated therein. 
MCWO and MCWl may each contain, for example. 32 bits of information regarding current microprogram 
eo execution environment 

Referring to MCWO« MCWO includes 6 execution environment subfields. Bits 0 to 3 Inclusive contain a 
Top Of Stack Counter (TOSCMT) subfield which is a pointer to Current Frame of accelerated Microstack 
(MiS) 10368. TOSCNT field is initially set to point to Frame 1 of MIS 10368. Bits 4 to 7 indus'n^e comprise a 
Top of Stack -1 Counter (T0S-1CT) subfield which Is a pointer to Previous Frame of accelerated MIS 10368, 
€S that is to the MIS 10368 frame proceeding that pointed by TOSCNT subfield. TOStCNT subfield is initially . 
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set to Frame 0 of MIS 10368. Bits 8 to 1 1 inclusive comprise a Bottom of Stack Counter (BOSCNT) subfield 
which is a pointer to Bottom Frame of accelerated MIS 10368. BOSCNT subfield is initially set to point to 
Frame 1 of MIS 10368. TOSCNT, T0S-1CNT, and BOSCNT subfields of MCWO may be read, written, 
incremented and decremented under microprogram control as frames are transferred between MIS 10368 

5 and a SS 10336. . . « \, u 

Bits 17 to 23 Inclusive and Bits 24 to 31 inclusive of MCWO comprise, respectn^ely. Page Number 
Register (PNREG) and Repeat Counter (REPCTR) subfields which, together, comprise a microinstructjon 
address pointing to a microinstruction currently being vmtten Into FUSITT 11012. 

Bits 12 to 15 inclusive of MCWO comprise an Egg Timer (EGGT) subfield which will be described further 

10 below wHh respect to TIMERS 20296. Bit 16 of MCWO is not utilized in a present embodiment of CS 101 10. 
Referring to MCWl , MCW1 is comprised of four subfields. Of the 32 bits comprising MCW1 , Bits 0 to 15 
Induswe and Bits 24 and 25 are not utilized in 3 present embodiment of CS 10110. Bit 16 is compnsed of a 
Condition Code (CC) subfield indicating results of certain test conditions in JP 10114. As previously 
described CC subfield is automatically saved and restored in RCWS 10358 RCWs. 

35 Bits 17 to 19 inclusive of RCW1 comprise an Interrupt Mask (IM) subfield. The three bits of IM subfield 
are utilized to Indicate a hierarchy of non-lnten^ptible JP 10114 mlcroinsUiiction control operating states. 
That is, a three bit code stored therein Indicates relative power to Interrupt between three otherwise 
nonlnterruptlble JP 10114 operating states. Bits 20 to 23 inclusive comprise an Interrupt Request (IR) 
subfield which indicate intemipt Request. These Interrupt Requests may include, for example, Egg Timer 

20 Overflow, interval Timer Overflow, or Non-Fatal Memory Error, as have been previously described. Finally, 
Bite 26 to 31 induslve comprise a Trace Trap Enable HTR) subfield indicating which Trace Trap Events, 
ptevioudy described, are currently enabled. These enables may include Name Trace Enable, Logical 
Retrace Enable. Logical Write Trace Enable, SOP Trace Enable, Microinstruction Enable, and 
Mtcroinstniction Break point Enatsie. 

25 MCWO and MCW1 has been described above as if residing in registers having Individual, discrete 
existence, that is MCW1 20290 and MCWO 20292. In a present embodiment of CS 10110, MCWl 20290 and 
MCWO 20292 do not exist as a unified, discrete register structure but are instead comprised of Indhrtdual 
registers having physical existence in other portions of FUCTL 20214. MCWl 20290 and MCWO 20292, and 
MCWl and MCWO, have been so described to more distinctly represent the structure of information 

50 contained therein. In addition, this approach has been utilized to illustrate the manner by which current JP 
10114 execution state may be controlled and monitored through JPD Bus 10142. As indicated in Rg. 202, 
MCWl 20290 and MCWO 20292 have outputs connected to JPD Bus 10142, thus allowing current execution 
state of JP 10114 to be read out of FUCTL 20214. Individual bits or subfields of MCWO and MCWl may, as- 
previously described, be written by rnicroinstruction control provided by FUSITT 11012. In a present 

3S physical embodiment of CS 10110, those registers of MCWO 20292 containing subfields TOSCNT, TOS- 
ICiNJT, and BOSCNT reside in RAG 20288. Those portions of MCWO 20292 containing subfield EGGT reside 
In TIMERS 2a)29a MCWO 20292 registers contain PNREG and REPCTR subfields are physically comprised of 
REPCTR 20280 and PNREG 20282. In MCWl 2020), CC subfield exists as output of FUCTL 20214 test 
drcuits. Those MCWl 20290 registers containing IM. IR, and TTE subfields reside within EVENT 20284. 

<o Ha^rfng described FUCTL 20214 stmcture and operation as regards RCWS 10358, MCW1 20290 and 
MCWO 20292, FUCTL 20214, BAG 20288 will be described next below. 



ace. Register Address Generator 20228 (Fig. 253) ^ . * 

45 Referring to Fig. 253, a partial blodc diagram of RAG 202^, together with diagramic representation of 
GRF 10354, BIAS 20246 and RCWS 10358. is shown. As previously described, JP 10114 register and stack 
mechanisms include Genera) Register File (GRF) 10354. BIAS 20246, and RCWS ^03^8 G^F 10^^ 
present embodiment of CS 10110, a 256 word by 92 bit wide array of regi^ers GRF 10354 is divi^ 
horizontally to provide Global Registers (GRs) 10360 and Stack Registers <SRs) 10362, each of whid^ 

5D contains 128 of GRF 10354's 256 registers. GRF 10354, that is both GRsI 0360 and SRslW 

vertically into three vertical sections designated as AONGRF 20232, OFFGRF 202^. ^lil^^^l?^^^^^^ 
AONGRF 20232, OFFGRF 20234, and LENGRF 20236 are, respechvely, 28 bits, 32 bits, and 32 wnde. GRs 
10360 is utilized as an array of 128 individual registers, each register containing one 92 bit word. SRs i oaej 
is structured and utilized as an array of 16 register frames wherein each frame comains eight ^^J^ters and 

ss each register contains one 92 bit wide word. Eight of SR 10362's frames are ^^^^^J^^j^'^^^^^^^ 

10362 and the remaining eight of SR 10362's frames are utilized as Monitor Stadc WOS) 1^0. For 
addressing purposes only, as described further below, GRs 10360 is regarded as being structured m tne 

same manner as SRs 10362, that Is as 16 frames of eight registers each. . 

BIAS 20246, as previously described, is a register array whhin BIAS 20246. BIAS 20246 conte^^^^^ 

so bH wide registers, or words, and operates in parallel with and is addressed m parallel with SR 10362 portion 
of GRF 10354. RCWS 10358 is, as previously described, an array of 16 registers, ^o^?^, wherem e^^^ 
register contains one 32 brt RCW. RCWS 10358 Is structured and operates in parallel with SRs 103^with 
each RCWS 10358 register corresponding to a SR 10362 frame of eight registers. As descnbed below, 
RCWS 10358 is addressed in parallel with SR 10362's frames. 

65 Source and Destination Register Addresses (SOAR) for selecting a GRF 10354 register to be. 
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''esp^Vely, read from or written to are provided by RAG 20288. As described above BIAS 20246 operates 
and is addressed in parallel with SR 10362 portion of GRF 10354, that Is parallel with SRs 10362. BIAS 20246 
registers are thereby connected to and in parallel with address inputs of SRs 10362 and are addressed 
concurrently with GRs 10360. Registers RCWS 10358 also operate and are addressed in parallel with SRs 
10362. Address Inputs of RCWS 10358's registers are thereby connected in parallel with address inputs of 
SR 10362's registers. 

RAG 20288's address inputs to GRF 10354, and to BIAS 20246 and RCWS 10358, may select registers 
therein to be either source registers, that Is registers providing data, or destination registers, that is 
registers receiving data. RAG 202^s address outputs are designated as output Source and Destination 
Register Address (SDADR) of RAG 20288. RAG 20288's SDADR output is connected to address input of 
register comprising GRF 10354, BIAS 20246, and RCWS 10358. As descnbed above, SRs 10362 are 
structured as 16 frames of 8 registers per frame and RCWS 10358 is structured as a corresponding 16 
frames of one register per frame. GRF 10354 and BIAS 20246 are structured and utilized as angle registers 
but, for addressing purposes, are regarded as being comprisBd of 16 frames of 8 registers per frame. Each 
SDADR output of RAG 20288 is an 8 bit vwrd wherein the most significant bit indicates whether the 
addressed register, either a Source or a Destination Register, reside in GRs 10360 or within SRs 10362, BIAS 
20246, and RCWS 10358. The four next most significant bits compnse a frame select field for selecting one 
of 16 frames within GRs 10360 or within SRs 10362, BIAS 20246, and RCWS 1035a The three least 
significant bits comprise a register select field selecdng a particular register within the frame selected by 
frame select field. 

Within a single system clock cycle, SDADR output of RAG 20288 may select a source register and data 
may be read from that source register, or SDADR output may select a destinatidn register and data may be 
wHtten into that destinaddn register. As previously described, each JP 10T14 microinstruction requires a 
minimum of two-«yslem dock cycles for execution, that is at first docdc cycle in State MO and a second 
clock cyde in State Ml. During a single microinstruction therefore, a source register may be selected and 
data read from that source register, and a destination register selected and data written into that 
destination register. Certain operations, however, may require more than one microinstruction for 
execution. For e)rample, a read-modify-wite operation wherein data Is read from a particular register, 
modified, and written back into that register may "require two or more microinstructions for execution. 

Referring first to RAG 20288 structure, RAG »)288 includes MISPR 10356. MISPR 10356 indudes Top Of 
Stack Counter fTOSCNT) 25310, Top Of Stack-1 Counter fTOS-ICNT) 25312, and Bottom Of Stack Counter 
(BOSCNT) ^14. Coments of TOSCNT 25310, TOS-lCf^ 25312 and BOSCNT 25314 are respectively, 
pointers to Current Previous, and Bottom frames of SRs 10362, that is, to MIS 103®. As will be described 
below, these pointers are also utilized to address MOS 10370. TOSCNT 25310, T0S-1CNT 25312, and 
BOSCNT 25314 are each four bit binary counters comprised, for example, of SN74S163S. 

Data inputs of TOSCWT 25310 to BOSCINTT 25314 are connected from JPD Bus 10142- Control Inputs of 
TOSCNT 15310 to BOSCNT 25314 areconnected from microinstruction contnji outputs of FUSITT 11012. 
Data outputs of TOSCNT 25310 to BSOCNT 25314 are connected to data inputs of Source Register Address 
Multiplexer (SRCADR) 25316 and to data inputs of Destination Register Address Multiplexer (DSTADR) 
263ia Data outputs of TOSCNT 25310 and BOSCNT 25314 are connected to inputs of Stack Event Monitor 
Logic (SEM) 25320. 

Source and destination frame addresses are selected, as will be described further below, by SRCADR 
25316 and DSTADR 25318 respectively. In addition to data Inputs from TOSCNT 25310 and BOSCNT 25314, 
data Inputs of SRCADR 25316 and DSTADR 25318 are connected from microinstruction word CONEXT 
subfield output from FUSITT 11012. Control inputs of SRCADR 25316 and DSTADR 25318 are connected 
from, respectively, microinstruction word RS and RD subfield outputs from FUSITT 11012. Source Frame 
Address Reld (SRCFADR) output of SRCADR 25316 and Destination Frame Address Reld (DSTFADR) 
output of DSTADR 25318 are connected to inputs of Source and Destination Register Address Multiplexer 
(SDADRMUX) 25322. SRCFADR and DSTFADR comprise franne s^ect fields of RAG 20288, SD/OTR outputs 
for, respectively, source and destination registers. 

In addition to SRCFADR and DSTFADR outputs of ADRSRC 25316 and DSTADR 25318, SDADRMUX 
25322 receh^es microinstruction word SRC and DST subfield inputs from microinstruction outputs of 
FUSITT 11012. As previously described, SRC subfield is a 3 bit number designating a source register, that 
is, a source register within a frame selected by SRCFADR. DST is similarty a 3 bit number selecting a 
destination register within a frame indicated by DSTFADR. SRC subfield input to SDADRMUX 25322 is 
concatenated with SRCADR 25316 to respectively comprise, as described above, register and frame fields 
of a source register SDADR output of SDADRMUX 2532Z Similarty, DST subfield Is concatenated with 
DSTTOADR output of DSTADR 25318 to comprise, respectively, register and frame subfields of a 
destination register SDADR output of SDADRMUX 25322. Selection between source and destination 
register address Inputs to SDADRMUX 25322, to generate a corresponding source of destination register 
SDADR output of SDADRMUX 25322 Is controlled by microinstruction control inputs {not shown for clarity 
of presentation) connected to control inputs of SDADRMUX 25322. ROWS 25324 is a PROM decoding MD 
field from microinstruction words during reads from MEM 10112 and provides register select field of 
destination register address and selects one of the pointers as frame select field. 

An Event output of SEM 25320 is connected to an input of EVENT 20284, previously described. 
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SRCADR 25316, DSTADR 25318, and SDADRMUX 25322, as will be described further below, operate as 
multiplexers and may be comprised, for example, of SN74S153s. 

Having described structure and organization of GRF 10354, BIAS 20246, and HONS 10358, and 
structure of RAG 20288, operation of RAG 20288 to generate Source of Destination Register Address 

* outputs SDADR will be described next below. Addressing of JP 1 01 1 4's stack mechanism, comprising SRs 
10362 and RCWS 10358, wfll be described first, followed by addressing of GRs 10360 and BIAS 20246. 

SR 10362 portion of GRF 103S4, RCWS 10358, and BIAS 20246 are addressed by Current, Previous, and 
Bottom Frame Pointers contained, respectively, in TOSCNT 25310, T0S-1CNT 25312, and BOSChTT 25314. 
Current Previous, and Bottom Pointers comprise frame select fields of SDADRMUX 25322, As previously 

^0 described. Current, Previous and Bottom Pointer outputs of TOSCNT 25310 to BOSCNT 25314 are provided 
as inputs of SRCADR 2B316 and DSTADR 25318. Mlcroinstoiction word RS subfield to control input of 
SRCADR 25316 selects either Current Previous or Bottom Pointer input of SRCADR 25316 to compnse 
SRCFADR output of SRCADR 25316, that is to be frame select field of source register address. Similariy, 
microinstruction word RD subfield to control input of DSTADR 25318 concurrently selects either Current 
Previous, or Bottom Pointer inputs of DSTADR 25318 to comprise DSTADR SSSWs concun^ntly selects 
either Current Previous, or Bottom Pointer inputs of DSTADR 25318 to comprise DSTADR 25318s 
DSTFADR output that is frame select field of destination register address. As described above, SRCFADR 
and DSTFADR are provided as inputs to SDADRMUX 25322. Microinstruction word SRC and DST subfield 
inputs to SDADRMUX 25322 concurrently determine, respectively, source and destination registers withm 

50 source and destination frames specified by SRCFADR and DSTF;U)a SDADRMUX 25322 then, operating 
under microinstruction contr<rf, selects either SRCFADR and SRC to comprise SDADR output to SR 1 0362 as 
a source register address or selects DSTFADR and DST as SDADR output specifying a destination register 
address. By microinstruction control of SRCADR 25316, DSTADR 25318, and SDADRMUX 25322, a CS 
101 10 microprogram may select a source frame and register within SR 1 0362 and simultaneously specify a 

X possible different destination frame and register within SR 10362, All possible combinations of source 
frame and register and destination frame and register In GRs 10360, SRs 10362, BIAS 20246, and RCWS 
10358 are valid. 

Control of SRCADR 25316, DSTADR 1^18, and SDADRMUX 25322 in addressing SR 10362 portion of 
GRF 10354, and RCWS 10358, Is controlled. In part, by current CS 10110 state. Perdnent CS 10110 operating 

30 states, previously described, are State Ml and State RW. Wien CS 101 10 Is In neither State RW nor State 
Ml, SR 10362 is addressed through SRCADR 25316 and microinstruction word SRC subfield, that is SR 
10362 and RCWS 10358 are provided with source register addresses when CS 10110 is in neither RW nor 
Ml States. When CS 10110 enters State Ml, SR 10362 and RCWS 10358 is addressed through DSTADR 
25318 and by micro! nstnicdon word DST subfield. That is, SR 10362 and RCWS 10358 are provided with 

35 destination register addresses during State Ml. Similarly, SR 10362 and RCWS 10:^ are provided with 
destination register addresses when CS 10110 is operating in State RW, that is when data is being read 
from MEM 10112 and written into SR 10362 or RCWS 10358. In tiiis case, however, low order 3 bits of 
destination register address, that is register select field, are provided by RDS 25324, which decodes 
microinstruction word subfield MD (Memory Destination). RDS 25324 also provides a control input that 

^0 DSTADR 25318 to select one of Current Previous, or Bottom pointers from MISPR 1 0356 to comprise frame 
select field of destination register address. 

As stated above, frame select field of source and destination register addresses are provided from 
TOSCNT 25310, T0S-1CNT 25312, and BOSCNT :^14. As described above, the most significant bit of 
source and destination register address are forced to logic 1 or logic 0, depending upon whether GR 10360 

4S or SR 10362, BIAS 20246, and RCWS 10358 are being addressed. Contents of TOSCNT 25310 to BOSCNT 
25314, that is Current Previous, and Bottom Pointers, are controlled by microinstruction control outputs of 
FUSrrr 11012. current and Previous Pointers change as stacks are "pushed" or "popped" to and from MIS 
10368 as JP 10114 performs, respectively, calls and returns. Similariy, Current Previous and Bottom 
Pointers v^ll be Incremented or decremented as MIS 10368 frames are transferred between MIS 10368 and 

50 MEM 10112, as previously described with respect to CS 10110's Stack Mechanisms. 

Referring first to Current and Previous Pointer operation. Current and Previous Pointers in TOSCNT 
25310 and T0S-1CNT 25312 are Initially set, respectively, to point to Frames 1 and 0 of MIS 10368 by being 
loaded from JPD Bus 10142. TOSCNT 25310 and T0S-1CNT 25312 are enabled to count when two 
conditions are met Rrst condition is dependent upon current operating state of CS 101 10. TOSCNT 25310 

55 and T0S-1CNT 2531 2 will be enabled to count during last system clock cycle of CS 1 01 1 0 operating States 
Ml or AB. Second condition is dependant upon whether JP 10114 is to execute a call or return. TOSCNT 
25310 and T0S-1CNT 25312 may be enabled to count If a current mlcrolnstmction indicates JP 101 14 is to 
execute a call or return, or if CS 101 10 is exiting State AB as exit from State AB is an implied call operation. 
Both a call and an implied calt that is exit from State AB, will cause TOSCNT 25310 and T0S-1CNT 25312 to 

60 be incremented. A return will cause TOSCNT 2531 0 and T0S1 CNT 25312 to be decremented. 

Referring to BOSCNT 25314, Bottom Frame Pointer is initially loaded from JPD Bus 10142 to point to 
MIS 10368 Frame 1. Again, incrementing or decrementing of BOSCNT 25314 Is dependant upon CS 10110 
operating state and operation to be performed. BOSCNT 25314 is enabled to count upon exiting from State 
Ml . In addition, DEVCMD subfield of a cun-ent microinstruction word must indicate that BOSCNT 2531 4 Is 

& to be Incremented or decremented. BOSCNT 25314 will be incremented or decremented upon exit from 
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State Ml as indicated by microinstruction word DEVCMD subfield. 

SEM 25320 monitors relative values of Current and Bottom Pointers residing in TOSCNT 25310 and 
BOSCNT 25314 and provides outputs to EVENT 20284 for purposes of controlling operation of Ml 10368 
and MOS 10370. SEM 25320 is comprised of a Read Only Memory, for example 93S427s. receiving Current 

s and Bottom Pointers as inputs. SEM 25320 detects 3 Events occurring in operation of TOSCNT 25310 and 
BOSCNT 25314, and thus in operation of MIS 10368 and MOS 1 0370. Brst SEM 25320 detects an MIS 10368 
Stack Overflow. This Event is indicated if the present value of Currant Frame Pointer is greater than 8 larger 
than the present value of Bottom Frame Pointer. Second, SEM 25320 detects when MIS 10368 contains only 
one frame of Information. This event is indicated if the value of Current Frame Pointer is equal to the value 

fO of Bottom Frame Pointer. In this case, the previous frame of MIS 10368 resides In MEM 10112 and must be 
fetched from MEM 10112 before a reference to the previous stack frame may be made. Third, SEM 25320 
detects when MIS 10368 and MOS 10370 are full. This Event is indicated if the present value of Current 
Frame Pointer Is 16 larger than the present value of Bottom Frame Pointer. When this Event occurs, any 
further attempt to write a frame onto MIS 10368 or MOS 10370 will result in a MOS 10370 Stack Overflow. 

ts EVENT 20284 responds to these Events indicated by SEM 25320 by initiating execution of an appropriate 
Event Handling microinstruction sequence, as previously decribed. It should be noted that MIS 10368 and 
MOS 10370 are addressed in the same manner, that is through use of Current, Previous and Bottom Frame 
Pointers and certain microinstruction word subfields. Primary difference betw^n operation of MIS 10368 
and MOS 10370 is in the manner In which stack overflows are handled- In the case of MIS 10368, stack 

2G frames are transferred between MIS 10368 and MEM 10112 so that MIS 10368 is effectively a bottomless 
stack. MOS 10370, however, contains a maximum of 8 stack frames, in a present embodiment of OS 10110, 
so that no more than eight Events may be pushed onto MOS 10370 at a given time. 

GR 10360 is addressed in a manner similar to SR 10362, BIAS 20246, and ROWS 10358, that is through 
ADRSRC 25316, DSTADR 25318, and SDADRMUX 25322. Again, regl^r select fields of source and 

2S destination register addresses are provided by microinstruction word SRC and DST subfields. Frame select 
field of source and damnation register addresses is, however, specified by microinstruction word CONEXT 
subfield. In this case, microinstruction word RS and RD subfields specify that frame select fields of source 
and destination register addresses are to be provided by CONEXT subfield. Accordingly, ADRSRC 25316 
and DSTADR 25318 provide CONEXT subfield as SRCFADR and DSTFADR inputs to SDADRMUX 25322. 

30 Having described structure and operation of RAG 20288, TIMERS 20296 will be described next below. 
Referring to Rg. 254, a partial block diagram of TIMERS 20296 is shown. As indicated therein, TIMERS 
20296 includes Interval Timer (INTTMR) 25410, Egg Timer (EGGTMR) 25412, and Egg Timer Dock Enable 
Gate (EGENB) 25416. 

35 

d.d-d. Timers 20236 (Rg. 254) 
Refening first to INTTMR 25410, a primary function of INTTMR 25410 is to maintain CS 10110 
architectural time as previously described with reference to Rg. 106A and previous descriptions of CS 
10110 UID addressing. As described therein, a portion of all UID addresses geirarated by all CS 10110 

40 systems is an Object Serial Number (OSN) field. OSN fidd uniquely defines each object created by 
operation of or for use in a particular CS 101 10. OSN field of an object's UID is, in a particular CS 10110, 
genmted by determining time of creation of that object relative to an arbitrary historic starting time 
common to all CS 10110 systems. That time is maintained within a MEM 10112 storage space, or address 
location, but is measured by operation of INTTMR 25410. 

4s INTTMR 25410 is a 28 bit counter clocked by a 110 Nano-Second Clock (110NSCLK) input and is 
enabled to count by a one MHZ Dock Enable Input (CLK1MHZENB). INTTMR 25410 may thereby be clocked 
at a one M HZ rate to measure one microsecond intervals. Maximum time interval whidi may be measured 
by INTTMR ^10 is thereby 268j435 seconds. 

As indicated in Fig. 254, INTTMR 25410 may be loaded from and read to JPD Bus 10142. In normal 

50 operation, the MEM 10112 location containing architectural time for a particular CS 10110 will be loaded 
with currem architectural time at time of start up of that particular CS 101 ia INTTMR 25410 will 
concurrently be loaded with all zeros. Thereafter, INTTMR 25410 will be clocked at one microsecond 
intervals. Periodically, when INTTMR 25410 overflows, architectural time stored in MEM 10112 will be 
accordingly updated. At any time, therefore, current architectural time may be determined, down to a one 

55 microsecond Increment, by reading architectural time from the previous updated architectural time stored 
in MEM 10112 and elapsed interval since last update of architectural time from INTTMR ^10. In the event 
of a failure of CS 10110, architectural time in MEM 10112 and INTTMR 25410 may be saved in MEM 10112 
by reading elapsed intervals since last architectural time update. When normal CS 10110 operation 
resumes, INTTMR 25410 may be reloaded with a count reflecting current architectural time. As indicated in 

^ Rg. 254, INTTMR 25410 is loaded from JPD Bus 10142 when INTTMR 25410 is enabled by a Load Enable 
input (LDE) provided from DP 1011 8. 

Referring to EGGTMR 25412, certain CS 10110 Events, in particular Asychronous Events previously 
described with reference to EVENT 20284, are received or acknowledged by EVENT 20284 only at 
conclusion of State Ml of first microinstruction of an SOP. As certain CS 1 01 10 microinstru<^ons have long 

^ execution times, these Asynchronous Events may be subjected to an extended latency, or waiting, interval _ 
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before being serviced. EGGT^AR 2541i In effect, "'^asures laten^ time o^^^^^ Events 
S^d pre.. an output ^EVENT^^ 

As indicated in Fig. 254, EGGTMR »412 is CKWKea dy a ■ lu ^1 of the first microinstruction 

EGG™R25412isinit.allys«tozerobvtoadmputaDZRO^^^^ ^„bf.eld of a 

of each SOP executed by CS 101 a or when f 
mlcroinstmc^onword.EGGTMR2M12.sm^m^^^^ 

EG6ENB 25416. There are two conditions n««««?'Y^°r,^^°^ to EGGENB 25416 from 

is occurrence of an Asychronous Event which is •"^"•"^^^^Xavf elap^ last increment of 
EVENT 20284 Second condition is that 16 or more ""'^ o^^"^!, J^^^tKR 2&4io w^^^^ as shown 
EGGTMR 25412. This inten/al is measured by an o^^^ 

in Rg. 254. is connected to an '"P|rt ^Mia EGOT beginning of an SOP if an 

overflow and generate output OVRFLW to EVEf^TT 266rmcrOTec^^ ^ g^p 

Asychronous Event has occurred and .f at ^^^^.'^^^^^J^^^^^^^^As^ainmiiiBfef^ 
EGGT^flR ^412 thereby insures a maximum service latency of 2S6 microseconos iw «sy 

e.e.e. Fetch Unit 10120 Interface toExecutt Unh 101^ nrfmarilv comprised of EUDIS Bus 
Rnally, as previously descnl^d FU 101 

2020$. for providing EUOPsto EU 1012^8 EUSTIT and FU»a following description of EU 

Bus 20206 has been previously for conditions signalled fram 

10122. FUINT 20298 Is pnmanly primarily comprised of gates 

EU 1 0122 so that these Events may be serviced. In thts «3"™;^"^ ^ EVENT 20284. Another 
Leiving Event Requests from EU 10122 and P^^^JItio^^KSrSSSt^'Sgnal generated by FU 

interface function performed by FUINT 20^8 is g«««fion^^^^ 8 « ^,20 has been 

EU 10122 to FU 10120 or MEIV1 10112. i«.|udina OESP 20210, MEMINT 20212. and 

Having dea«ibed st^cture '''^X^Jlu mA^'^^^^^^ 
FUCTL 20214, the structure end operation at EU 101^ win oe uesviiuavi 

unpa^TSa\ and sing^anddoublepredslon floating point arft^^^ 

of EU 10122 is to relieve FU 10120 of certain arithmetic oP«ra«°"Sv*»yr*?,'^'^^S^ 
•^'^rai^ferofoperandsf^mMB^^^^^^ 

arithmetic operations from EU 10122 to *^*^22■J^Z^,^H \l%liW^22 bv EUSOT 20266. EU 10122 
initiated by FU 10120 by EU 10i:2 Depatch EU 

Dispatch Pointers -«yj"-««^,'»*,f'"*r^ "^^^^^^^ 10122 Dispatch 

10122 operations assisting in handling of CS 10110 e^ent& ~ P',^""^^ J. gn 10122's EUSITT 
Pointers are translated into sequences of '"'^^^"f ™«J°Pf 

which IS similar in structure and operation to FUSITT ''^^^J^J^'^,^,^^^^^}^^^^'^ 
indud^ a command aueue for rece ving and stonng sequences of EU lOlZ-J "'*'*^^|rr;Vrr« iranA 

double precision floating point ope'^'o'^-.'^"'-!,^;* "J^® and arittimetic operations with 
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MULT 20314 and EXP 20316 and prealignment and normalization of mantissa and e^^"®"^. /If *f 
floating point operations. Rnally, TSTINT 20320 perfomns certain test operations with regard to EU 1012Z s 
operations, and is the interface between EU 10122 and FU 10120. 

a. General Structure of EU 10122 

1. Execute Unit 1/0 20312 ^. _ ^ 

Referring first to EUlO 20312, EUlO 20312 includes Operand Buffer (OPB) 20322, Final Result Output 
Multiplexer (FROM) 20324, and Exponent Output Multiplexer (EXOM) 20326. OPB 20322 has first and 
second inputs connected, respectively, from MOD Bus 10144 and JPD Bus 10142. OPB 20322 has a first 
output connected to a first input of Multiplier Input Multiplexer (MULTIM) 20328 and MULT 20314. A 
second output of OPB 20322 is connected to first inputs of Inputs Selector A (INSELA) 20330 and Exponent 
Execute Unit General Register File Input Multiplexer (EXRM) 20332 in EXP 20316. 

FROM 20324 has an output connected to JPD Bus 10142. A first input of FROM 20324 is connected from 
output of Multipfier Execute in General Register Rle Input Multiplexer {MULTRM) 20334 and MULT 20314. 
A second input of FROM 20324 is connected from output of Finai Result Register (RFR) 20336 of MULT^ 
20314. EXOM 20326 has an output connected to JPD Bus 10142. EXOM 20326 is a first input connected from 
output of Scale Register (SCAi^) 20338 of EXP 20316. EXOM 20326 has second and third inputs 
connected from outputs of, respecth^ely, Next Address Generator (NAG) 20340 and Command Queue 
(COMQ) 20342 of EUCL 20310. 



2. Execute Unit Control Logic 20310 ^ . ^ . _ 

Referring to EUCL 20310, EUCL 2031 0 includes NAG 20340, COMQ 20342, Execute Unit S Interprets 

25 Table (EUSnm 20344, and Microinstruction Control Register and Decode Logic {mCRDJ 20346. COMQ 
20342 has an input connected from EUDIS Bus »)206 for receiving SDPsfrom EUSDT 20266. COMQ 20342 
has as described above, a first output connected to a third Input of EXOM 20326, and has a second output 
connected to an input of NAG 20340. NAG 20340 has, as described above, a first <>^l^f°2l!!!f?^ 
second Input of EXOM 20326. NAG 20340 has a second output connected to a first Input of EUSITT 20344. 

30 As previously described, EUSITT 20344 corresponds to FUSITT 11012 and stores sequences of 
microinstructions for controlling operation of EU 101 22 in response to EU 10122 Dispatch Pointers from FU 
10120. EUSmr 20344 has a second input connected from JPD Bus 10142 and has an output connected to 
input of mCRD 20346. mCRD 20346 includes a register and logic for receMng a"^ ^^«3(xJing 
microinstructions provided by EUSITT 20344. in addition to an input from EUSTTT 20344. mC^D 20346 has 

3S first outputs providing decoded microinstruction control signals to all parts of EU 1 0122. mCRD 20346 also 
has a second output connected to a first input of Input Selecter B (INSELB) 20348 and EXP 20316. 



60 



ss 



eo 



es 



a Multiplexer Logic 20314 ^ ^ . , 

Referring to MULT 20314, MULT»>314 includes two parallel aritiimetic operation paths for performing 
addition, subtraction, multiplication, and division operations on packed decimal numbers, integer 
numbers, and mantissa portions of single and double precision floating point numbers. MULT 20314 also 
Includes a related portion of EU 10122's general register file, a memory for stonng constants used m 
arithmetic operations, and certain input data selection circuits. That portion of EU 10122's GRF reading in 
MULT 20314 is comprised of Multiplier Register file (MULTRF) 20350. Output of MULTRF 20350 is 
connected to a second input of MULTIM 20328. A first input of MULTRF 20350 is co"ne«rtet^^ ou^ut of 
RFR 20336 and a second input of MULTRF 20350 is connerted from output of MULTRM 20334. First and 
second inputs of MULTRM 20334 are in turn connected, respectWely, from output of RFR 20336 and from 
output of Container Size Logic (C0NSI2E) 20352 of TSTINT 20320. 

MULTIM 20328 selects the data inputs to MULT 20314's arithm^c circuits and has, as previously 
described, first and second inputs connected respectively from first output of OPB 20322 and fre>m output 
of MULTRF 20350. Output of MULTIM 20328 is connected tiirough Multiplier (MULT) Bus 20354 to input of 
Multiplier Quotient Register (MQR) 20356 and to input of Nibble Shifter {NIBSHF) 2035a Another input to 
MQR 20356 and NIBSHF 20358 is provided by Constant Store {CONST) 20360. CONST 20360 is a memofy 
for storing constant values used n MULT 20314 operations. Output of CONST 20360 is connected to mjlT 
Bus 20354. MULT 20314's arithmetic circuits may tiiereby be provided with inputs from OPB 20322, 
MULTRF 20350. and CONST 20360. u • 

MULT 20314's arithmetic circuitry is comprised of two, parallel arithmetic operation patiis having, as 
common inputs, outputs of MULTIM 20328 and CONST 2036a Common termination of these parallel 
aritfimetic operation paths is Rnal Register Shifter (FRS) 20362. Afirst arithmetic operation p^^ is Provided 
through NIBSHF 20358, v^ose input ts connected from MULT Bus 20354. NIBSHF 20358's output is 
connected to a first Input of FRS 20362 and a control input of NRBSHF 20358 is connected from an output of 
MuHiplier Control Logic (MULTCNT) 20364 and MULTCNTL 2(^18. ^^^^ ohnv« 

MULT 20314's second arithmetic operation path is provWed through MQR 20^. As deswibad above, 
MQR 20^6^5 input is connected from MULT Bus 20354. MQR 29^6's output Is connected to first and 
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second inputs of Times 1 And Times 2 Muhiply Shifter (MULTSHFT12) 20366 and Times 4 And Times 8 
Multiply Shifter (MULTSHFT48> 20368. Outputs of MULTSHFT12 and MULTSHFTS are 
respectively, to first and second inputs of Rrst Multiplier Arithmetic and Logic Unit (MULTALUK 203/0, 
MULTALU1 20370*8 output Is connected to input of Multiplier Working Register (MWR) 20372. Output of 
MWR 20372 is connected to a first input of Second Multiplier Arithmetic and Logic Unit (MULTALU2) 20374. 
A second input of MULTALU2 20374 is connected from output of RFR 20336. Output of MULTALU2 is 
connected to a second input of FRS 20362. As described above, first input of FRS 20362 is connected from 
output of NIBSHF 20368. Output of FRS 20362 Is connected to Input of RPR 20336. 

As described above, output of RFR 20336 is connected to second input of MULTALU2 20374, to first 
input of MULTRF 20350, to first input of MULTRM 20334, and to second input of FROM 20324. Output of 
RFR 20336 is also connected to input of Uading Zero Detector (L2D) 20376 of MULTCNTL 20318. and to 
inputs of Exception Logic (ECPT) 20378, CONSIZE 20352, and TSTINT 20320. 



4. Exponent Logic 20316 

Referring to EXP 20316, as previously described EXP 20316 performs certain operations with respect to 
exponent fields of single and double precision floating point number in EU 10122 floating point operations. 
EXP 20316 includes a second portion of EU 10122's general register file, shown herein as Exponent Register 
RIe (EXPRF) 20380. Although indicated as indhridual register fll^, MULTRF 20350 and EXPRF 20380 
comprise, as in GRF 10354* a unitary register file structure vwth common, parallel addressing of 
corresponding registers therein. 

Output of EXPRF 20380 is connected to a second inptt of INSELA 20330. Afirsl Input of EXPRF 20380 is 
connected from output of EXRM 20332. As previously described, a first input of EXRM 20332 is connected 
from second output of OPB 20322 through EXPQ Bus 20325. A second input of E^M 20332 is connected 
from output Scale Register (SCALER) 2033a A second input of EXPRF 20380 is connected from output of 
Sign Logic (SIGN) 2038Z Input of SIGN 20382 is connected from second output of SCALER 20338. 

INSELA 20330, INSELB 20348, Exponent ALU (EXPALU) 20384 and SCALER 20338 comprise EXP 
^31 6*s arithmetic circuitry for manipulating exponent fields of floating point numbers- INSELA 20330 and 
INSELB 20348 select, respectively, first and second inputs to EXPALU 20384. As previously des<^bed, a first 
input of INSELA 20330 is connected from second output of OPB 20322 through EXPQ Bus 20325. Second 
input of INSELA 20330 is connected from output of EXPRF 20380. Output of INSELA 20330 is connected to 
first input of EXPALU 20384. Rrst input of INSELB 20348 is, as previously described, connected from a 
second output of mCRD 20346, S«»nd input of INSELB 20348 is connected from output of OPB 20322 
through EXPQ Bus 2032S. Third input of INSELB 20348 is connected from output of SCALER ^38 and 
fourth input of INSELB 20348 is connected from output of L2D 20376. Output of INSELB 20348 is connected 
to second input of EXPALU 20348. Output of EXPALU 20348 Is connected to input of SCALER 20338. 

As previously described, second output of SCALER 20338 is connected with input of SIGN 20382 and 
first output is connected to second input of EXRM 20332 and to third Input of INSELB 20348. First output of 
SCALER 20338 is also connected to EXPQ Bus 20325, to first Input of EXOM 20326. and to a second input of 
MULTCNT 20364, 



5. Multiplier Control 20318 

As previously described, MULTCNTL 20318 provides certain control signals and information for 
controlling and coordinating operation of EXP 20316 and MULT 20314 in performing arithmetic operations 
on floating point numbers. MULTCNTL 20318 Includes LZD 20376 and MULTCNT 20364. Input of LZD 20376 
is connected from output of RFR 20336 through FR Bus 20337. Output of LZD 20376 are connected to a 
second input of MULTCNT 20364 and to fourth input of INSELB 2034a A second input of MULTCNT 20364 
is connected from output of SCALER 20338. As previously described, control ou4)ut of MULTCNT 20364 is 
connected to control inputs of NIBSHF 20358. 



6. Test and Interface Logic 20320 

Rnally, TSTINT 20320 includes ECPT 20378, CONSIZE 20352, and Testing Condition Logic (TSTCON) 
20386. In^ of ECPT 20378 and first input of CONSIZE 20352 are connected from output of RFR 20336 
through FR Bus 20337. A second input of CONSIZE 20352 fe connected from LENGTH Bus 20226. An output 
of CONSIZE 20352 is connected, together with other inputs from EU 10122 (not shown for clarity of 
presentation) to TSTCON 20386. Output of TSTCON 20386 (not shown for clarity of presentation) are 
connected to NAG 20340. TSTCON 20386 and ECPT 20378 have outputs to and inputs from FU 10120's 
FUINT 20298. 

Having described the overall structure of EU 1 0122 above, operation of EU 10122 will be described next 
below with aid of further diagrams which will be introduced as required. Finally, operation of TSTINT 20320 
will be described, including a description of the detailed control signal interface between EU 10122 and FU 
10120 through TSTINT 20320 and FUINT 20298. In addition to defining the Interface between EU 10122 and 
FU 10120. certain features of EU 10122 operation will be described wherein those operations are executed 
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in cooperation with MEM 10112 and FU 10120. For example, EU 10122's Stack Mechanisms, comprising in 
part portions of MULTRF 20350 and EXPRF 20^, resides partly in MEM 10112 so that operation of EU 
10122's Stack Mechanisms requires cooperative operations by EU 10122, MEM 10112 and FU 10120. 

5 . 

b. Execute Unit 10122 Operation (Rg. 255) 
1. Execute Unit Control Logic 20310 (Rg. 255) 

Refen-ing to Fig, 255, a more detailed block diagram of EUCL 20310 is shown. As described above, 
EUCL 20310 receives EU 10122 Dispatch Pointers through EUDIS Bus ^206 from EUSOT 20266 and FUCTL 
w 20214. EU 10122 Dispatch Pointers select certain EU 10122 microinstruction sequences for executing EU 
10122 arithmetic operations as required to execute user's programs, that is SOPs, and to assist in handling 
JP 101 14 Events. As described above, major elements of EUCL 20310 include COMQ 20342, EUSITT 20344, 
mCRD 20346, and NAG 20340. 

JS 

a.a. Command Queue 20342 
Inputs of COMQ 20342 are connected from EUDIS Bus 20206 to receive and store EU 10122 Dispatch 
pointers provided from EUSDT 2026a Each such EU 10122 Dispatch Pointer is comprised of two 
information fields. A first information field contains a 10 bit starting address of a corresponding sequence 

20 of microinstructions residing in EUSITT 20344. Second field of each EU 10122 Dispatch Pointer is a 6 bit 
field containing certain control information, such as information identifying data format of corresponding 
operands to be operated upon. In this case unit dispatch pointer control field bits specify whether operands 
to be operated upon comprise signed or unsigned integer, packed or unpacked dedmal, or single or double 
precision floating point numbers. 

25 COMQ 20342 is comprised of two one word wide by two word deep register files. A first of these 
register fiekte is comprised of SOP Command Queue Control Store <CQCS) 2K10 and SOP Command 
Queue Address Store (CQAS> 2551 2. Togetiier, CQCS 25510 and CQAS 2551 2 comprise a one word wide by 
two word deep register file for receiving and storing EU 10122 Dispatch Pointers corresponding to SOPs, 
that Is Dispatch Pointers for initiating EU 10122 operations directly concerned with executing a user's 

30 program. Address fields of these SOPs are received in CQAS 25512, while control fields are receh^ed and 
stored In CCK:s ^10. COMQ 20342 is thereby capable of recehring and storing up to two sequential EU 
10122 Dispatch Pointers corresponding to user program SOPs These SOP derived Dispatch Pointers are 
executed in the order received from FU 10120. EU 10122 is thereby capable of recehnng and storing one 
currentiy executing SOP Dispatch Pointer and one pending SOP CKspatch Planter. Further SOP Dispatch 

3S Pointers may be read into COMQ 20342 as previous SOPS are executed* 



b.b. Command Queue Event Control Store 25514 and Command Queue Event Address Control 
Store 25516 

40 Command Queue Event Control Store (CQCE) 25514 and command Queue Event Address Control 
Store (CQAE) 2^16 are similar in function and operation to, respectively. CQCS 25510 ad CQAS 25512. 
CQCE 2K14 and CQAE 25516 receive and store, however, EU 10122 Dispatch Pointers initiating EU 10122 
operations requested by FU 10120 as required vo handle JP 10114 Events. Again, CQCE 25514 and CQAE 
25516 comprise a one word wide by two word deep register file. CQAE 25516 recent and stores address 

45 fields of Event Dispatch Pointers, whHe CX2CE 25514 recedes and stores con^spondlng control fields of 
Event Dispatch Pointers. Again, COMQ 20342 is capable of recehring and storing up to two sequential Event 
Dispatch Pointers at a time. 

As indicated In Rg. 255, outputs of CQAS 25512 and CQAE 25516, that is address fields of EU 10122 
C^patdi Pointers are provided as inputs to Select Case Multiplexer <SCASE) 25518 and Starting Address 

50 Select Multiplexer (SAS) 25520 end NAG 20340, which will be described further below. Control field 
outputs of CQCS 2SB^0 and CQCE 25514 are provided as inputs to OPB 20322, described further betow. 



cc. Execute Unit S-lnterpreter Table 20344 

S5 Referring to EUSITT 20344, as described above EUSITT 20344 is a memory for storing sequences of 
mioxjinstructions for controlling operation of EU 10122 In resf»nse toEU 10122 Dispatch Pointers received 
from FU 1012). These microinstruction sequences may, in general, direct operation of EU 10122 to execute 
arithmetic operations in response to SOPs of user's programs, or aid direct execution of EU 10122 
operations required to service JP 10114 Events. EUSITT 20344 may be, for example, a 60 bit wide by 1,280 

€0 word long memory structured as pages of 128 words per page. A portion of EUSITT 20344's pages may be 
contained in Read Only Memory, for example for storing sequence of microinstructions for handling JP 
10114 Events. Remaining portions of EUSITT 20344 may be constructed of Random Access Memory, for 
example for storing sequences of microinstructions for executing EU 10122 operations in response to user 
program SOPs. This structure allows EU 10122 microinstruction s^uences concerned with operation of JP 

65 I0114's internal mechanisms, for example handling of JP 10114 Events, to be effectively permanently 
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Stored m EUS.TT 20344. That portion of EUSITT 20344 constructed of ^^^^ 

used to Store sequences of microinstructions for exeait ng SOPs. These Random Acc^Mem 

used as writable control store to allow sequences of inicrolmrtructoons for «tea^ SO^ of one or more 

S^jnguages currently being utilized by CS 10110 to be written Into EUSITT 20344 from MEM 10112 as 

' "'"5?;eviouslydescribed.EUSm-20344'ssecondinputisaData(DATA)inp^^^^ 
1014? EUSITT 20344'8 data Input is utilized to write sequences of 

from MEM 101 12 through JPD Bus 10142. EUSITT 20344's first input is an address (ADR) '"Pf 
S Srt of Address Driver (ADRD) 25522 end NAG 2<B40. '^'^^^ JP^::^,^'^^^^^^ offS 
n select wwd locations within EUSfTT 20344 for writing of microinstructions E^snr 20^. or tor 
lading of microinstructions from EUSITT 20344 to niCTO 2W46 to «nttoi ^ 
Generation of these address Inputs to EUSITT 20344 by NAG 20340 will be descnbed further below. 

d. d. Microcode Control Decode Register a>346 nar^-iniAft :. 
Output of EUSrrr 20344 is connected to input of mCRD 20346. As previousiy descnbed, mC WD 20346 «s 

a register for receiving microinstructions from EUSfTT 20344, and decoding logic for d«»dlng tho^ 
microinstructions and providing corresponding control signab to EU 10122. As '"*<»*f^ '"J^^. ^f^^^ 
Diagnostic processor Micro-Program Register (DPrnR) 25524 is a 60 bit regirter connected in para»el with 
output of EUSITT 20344 to input of mCRD 20346. DPmR 25S24 may be loaded with 60 bit "i'CJ«"«ruct'ons 
by DP 10118. Diagnostic microinstructions may thereby be provided directly to input of mCRD 20346 to 
provide direct microinstruction by mioroinstniction control of EU 10122, 

Outputs of mCRD 20346 are provided, in generel. to all poftlora of EU 101M to ~nUol jleteiled 
operati^s of EU 10122. Certain outputs of mCRD aB46 arejwnnected to .npu^^ 
Select Multiplexer (NASS) 25S26 and Long Branch Page Address Gate (LBPA6) 255M a^'^.^AG 20340^As 
will be des«ibed further below, these outputs of n»CRD 23046 are used m QeneratinQ address inp«^ « 
EUSITT 20344 v>*en particular microinstructions sequences call for Jumps Of "^"8. Branches to ot^^^ 
microinstruction sequences. Outputs of roCRD 20346 are also connertedin ,»raHel »° "^Pf^ of ExewJtion 
Unit Micro-Instruction Parity Check I^lc lEUmlPC) 2S530. EUmPC 25530 *eclcs panty of all 
micrdnstniction outputs of mCRD 20346 to detected errors In nnCRD 20346's outputs. 

e. e. Next Address Generator 20340 »w u Anon 
As described above, read and write addresses to EUSITT 20344 Provided by NAG 20340 tiiroughADWD 
25522. Address inputs to ADRD 25522 are provided from either NASS 25526 or Diagnostic Proc^r 
Address Register (DPAR) 25532. In normal opetatloa address Inputs to EUSm" SM^Iare PW^^®^*;";" 
NASS 25S26 as wlB be described momentarily. DP lOlia however, may 'oad EUSm OT««ridi^ into 
DPAR 25532. These addresses may then be read from DPAR 25632 throuflh ADRD 25M2 to indJViduaUy 
select address locations within EUSITT 20344. DPAR 25532 may be utilized, in particular^ provide 
addresses to allow stepping through of EU 10122 microinstruction sequences microinstrucbon by 

""'"itedraSted above, NASS 25526 is a multiplexer having '"P«rts from *w NAG »3«add^ 
sources. NASS 25526's first address input is from Jump (JMP) output of mCRD 20346 and IBPAG 25K», 
These address inputs are utilized, in part, when a cun-ent microinstniction 

to anottier microinstruaion or microinsu^ction sequence. Second address source is P"»vwled ^^'T SAS 
25620 and, in general, is comprised of starting addresses of microinstruction sequences. SASZ^Ois a 
multiplexer h^ing a first input from COAS 25512 and CQAE 25516 that « s^rt-j^^JJ^jJ 
microinstruction sequences corresponding to SOPs or for servicing JP 10114 Eyente. A'fO^^SASJBMO 
input Is provided from Subroutine Return Address Stadc (SUBRA) 25534. In genera^, and ^ v«H be 
drecribed further below, SUBRA 25534 operates as a stack mechanism for storing current rowroinstrucnon 
addresses of interrupted microinstruction sequences. These stored ^'^'^^^'^^ J.''^^^'^ 
utilized to resume execution of those interropted microinstruction sequenoes. 
NASS 25526 is provided from Sequential and Case Address Generator (SCAG) 25536. In general, SCAG 
25536 generates address to select sequential microinstructions vinthin particular microlrBtnietion 
sequences. SCAG 25536 also generates microinstruction address for '"«™i"«»™"'0" <^^„"'P^^'f ^„ ~ 
in^cated In Rg. 255. outputs of SCAG 25536 and of SAS 25520 are bused together to comprise a single 
NA^ S526 input SeleiSion between outputs of SCAG 25536 and SAS 25520 are provided by control 
inputs (not shoL for clarity of presentetion) to SCAG 25536 and SAS 25520. Se echon between NASS 
25526's address inputs is controlled by Next Address Source Select Control Logic (NASSC) 255OT, which 
provides control inputs to NASS 25526. NASSC 25538 is effe«i^«'v ' '""'«P'e'<%^S.f ''^^ 
from T5TC0N 20386 and TSTINT 20320. As will be described further below. TSTCON 20386 rnom^s 
certein operating conditions or states within EU 10122 and provides corresponding inputs to NASSC 25^ 
hWSSC ^ ^vely decodes these control Inputs from TSTCON 20386 to provide selection control 

'"'""hi^dtSSd overell structure and operation of NAG 20340. operation of NAG 20340 will be 
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described in further detail next below. 

Referring first to NASS 25526's address inputs provided from JMP output of mCRD 20346 and LBPAG 
2552B, this address source is provided to a!lov/ selection of a next microinstruction by a current 
microinstruction. JMP output of mCRD 20346 allows a current microinstruction to direct a Jump to another 
microinstruction within the same page of EUSITT 20344. NASS 25526's Input through LBPAG 25528 is 
provided from another portion of mCRD 20346*3 output specifying pages within EUSITT 20344. This input 
through I^PAG ^28 allows execution of Long Branch operations, that Is jumps from a microinstruction in 
one page of EUSITT 20344 to a microinstruction in another page. In addition, NASS 25526's input from JMP 
output of mCRD 20346 and through LBPAG 25526 is utilized to execute an Idle, or Standby, routine when 
EU 10122 Is notOHTcntly executing a microinstruction sequence requested by FU 10120. In this case. Idle 
routine directs TSTCON 20386 to monitor EU 10122 Dispatch Pointer Inputs to EU 10122 from RJ 10120. If 
no EU 10122 Dispatch Pointers are present in COMQ 20342, or none are pending, TSTCON 20386 vwll direct 
NASSC 25538 to provide control inputs to NASS 25526 to select NASS 25526's input from mCRD 20345 and 
LBPAG 25528. Idle routine will continually test for EU 10122 Dispatdi pointer inputs until such a Dispatch 
Pointer Is received into COMQ 20342. At this time, TSTCON 20386 wrill detect the pending Dispatch Pointer 
and direct NASS 25538 to provide control outputs to NASS 25526 to select NASS 25526's input from, in 
general, SAS 25520. TSTCOND 20386 and NASSC 25538 will also direct NASS 25526 to select inputs from 
SAS 25520 upon return from a called microinstruction to a previously interrupted microinstruction 
sequence. 

As described atove, SAS 25520 receives starting addresses from COMQ 20342 and from SUBRA 
25534. SAS 25520 will select the output of CQAS 2551 2 or of CQAE 25516 as the input to NASS 25526 when 
a new microinstruction sequence is to be initiated to execute a user's program SOP or to service a JP 10114 
Event SAS 25520 will select an address output of SUBRA 25534 upon retum from a called sub-routine to a 
previously executing but Interrupted sub-routine. SUBRA 25534, as described above, is effectively a stack 
mechanism for storing addresses of currently executing microinstructions when those microinstruction 
sequences are interrupted. SUBRA 25534 is an 11 bit wide by 8 word deep register with certain registers 
dedicated for use in stacking Event Handling microinstruction sequences. Other portions of SUBRA 25534 
are utilized for backing of microinstruction sequences for executing SOF^ that is for stacking 
microinstruction sequences wherein a first microinstruction sequence calls for a second microinstruction 
sequence. SUBRA 25534 is not operated as a first-in-first out stack, but as a random access memory 
wherein addr^ inputs selecting registers and SUBRA 2SS34 are provided by microinstruction control 
outputs of mCRD 20346. Operations of SUBRA 25534 as a stack mechanism ts thereby oomroHed by the 
microinstruction sequences stored in EUSITT 20344. As indicated in Rg. 255, addresses of current 
microinstructions of interrupted microinstruction sequences are provided to data input of SUBRA 25534 
from output of SCAG 25536, which will be described next below. 

As described above, SCAG 25536 generates sequential addresses to select sequential 
microinstructions within nriicroinstruction sequences and to generate microinstruction addresses for Case 
operations. SCAG 25536 Includes Next Address Register (NXTR) 25540, Next Address Arithmetic and Logic 
Unit <NAALU) 25542, and SCASE 25518. NAALU 2^2 is a 1 2 l»t arithmetic and logic unit Aflrst eleven bit 
input of NAALU 25542 is connected from output of ADRD 25522 and is thereby current address provided to 
EUSITT 20344. A second four kxt input to NAALU 25542 is presided from output of SCASE 25518, During 
sequential execution of a microinstruction sequence, output of SCASE 2^18 is binary zeros and carry input 
of NAALU is forced to 1. Output of NAALU 25542 vnn thereby be and address one greater than the current 
microinstruction acfclr^ provided to EUSITT 20344 and will thereby be the address of the next sequential 
microinstruction. As indicated in Rg. 255, SCASE 25518 recedes an input from output of SCAUER 20338. 
This input is utilized during Case operations and allows a data sensitNe number to be selected as SCASE 
25518's output Into second input of NAALU 25542. SCASE 25518's input from SCALER 20338 thereby 
allows NAG 20340 to perform mk^-oinstruciion Case operations wherein Case Values are determined by the 
contents of SCALER 20338, 

Next address outputs of NAALU 25542 are loaded into NXTR 25540, which is comprised of tri-state 
outpttt registers. Next address outputs of NXTR 25540 are connected, in common with output of SAS 
25520, to second input of NASS 25526 as described above. During normal execution of microinstruction 
sequences, therefore, SCAG 25536 will, through NASS 25525 and ADRD 25522, select sequential 
microinstructions from EUSITT 20344. SCAG 25536 may also, as just described, provide next 
microinstruction addresses in microinstruction Case operations. 

In summary, NAG 20340 is capable of performing all usual microinstruction sequence addressing 
operations. For example, NAG 20340 allows selection of next microinstructions by current 
rriicroinstructions, either for Jump operations or Long Branch operations, through NASS 25526's input 
from mCRD 20346*8 JMP or through LBPAG 25528. NAG 20340 may provide microinstruction sequence 
starting addresses through COMQ 20342 and SAS 25520, or may provide return addresses to interrupted 
and staclced microinstruction sequences through SUBRA 25534 and SAS 25520. NAG 20340 may 
sequentially address microinstructions of a particular microinstruction sequence through operation of 
SCAG 25536, or may perfomi mciroinstruction Case operations through SCAG 25536. 
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^ °Eg SibSmcture and operation of EUCL 20310, structure and operation of OPB 2(»22 will be 

described next below. As previously described, OPB 20322 «P!'^^' 

10112 and FU 10120 through MOD Bus 10144 and JPD Bus 10142. OPB 20322 may then perform certain 

operand format translations to provide data to MULT 20314 and EXP 20316 in the tonnats most efficiently 

utilteed by MULT 20314 and EXP 20316. As previously described. EU 10122 may perfomi anthmetic 

operations on integer, packed and unpacked decimal, and single or double precision floating point 

numbers 

In summary, therefore, OPB 20322 is capable of accepting integer, single and double precision floating 
point, and packed and unpacked decimal operands from MEM 10112 and FU 101:m and providing 
appropriate fields of those operands to MULT 20314 and EXP 20316 in the formats most efficientiv utilized 
by MULT 20314 and EXP 20316. In doing so, OPB 20322 extracts exponent and mantissa fields from single 
end double precision floating point operands to provide exponent and mantissa fields of these operandi to, 
respedively, EXP 20316 and MULT 20314, and also unpacks, or converts, unpacked deamal operands to 
packed decimal operands most efficiently utilized by MULT 20314. 

Having <te8cribed structure and operation of OPB 20322, structure and operation of MULT 20314 will be 
described next below* 



3. Multiplier 20314 (Figs, 257, 258) ^ . ... t- ^ H;v,;^i«n 

MULT 20314, as previously described, performs addition, subtraction, multiplication, and <3iviston 
operBtions on mantissa fields of single and double precision floating point operands, integer operands, and 
decimal operands. As described above with reference to OPB 20322, OPB 20322 «>"vens unP^^^^^ »"If 
operands to packed decimal operands to be operated upon by MULT 20314 MULT 20314 is thereby 
effectively capable of performing all arithmetic operations on unpacked dedmal operands. 

a.a. Multiplier 20314 Data Paths and Memory (Rg. 267) 

Referring to Rg. 257, a more detailed block diagram of MULT 20314'8 data paths and memory is 
shown. As previously described, major elements of MULT »014 include memory elements «o"^P"sed ot 
MULTRF 20350 and CONST 2)360, operand input and result ou^ut multiplexing logic Including MULTIM 
20328 and MULTRM 20334. and aritfimetic operation logic MULT 20314's operand input and result output 
multiplexing logic and memory elements will be described first, followed by description of MULT 20314 s 
arithmetic operation logic ^ . „ ^, • u ^• 

As previously described. Input data. Including operands. Is provided to MULT 20314 s arithmetic 
operation logic through MULTIN Bus 20354. MULTIN Bus 20354 may be provided with data frorn ttir^ 
sources. A first soun» is CONST 203G) which i$ a 512 word by 32 bit wide Read Only Memory. CONST 
20360 is utilized to store constants used in arithmetic operations. In particular, CONST 20360stofBs zone 
fields for unpacked decimal, that is ASQ character, operands. As previously desicribed, unpacked 
operands are received by OPB 20322 and converted to packed dedmal operands for more efticlem 
utilization by MULT 20314. As such, final result outputs generated by MULT 20314 from such (^randsare 
in packed dedmal fonnat As will be described below, MULT 20314 may be utilized to convert these Packed 
dedmal results Into unpacked dedmal results by insertion of zone fields. As indicated in Fig. 257, address 
inputs are provided to CONST 203^ from EXPO Bus 20325 and from output of »"CRO 2034& Sejec^ 
between these address inputs is provided through CONST Address Multiplexer (CONSTAM) 25710. CONST 
20360 addresses will, in general, be provided from EUCL 20310 but aHemately may be provided from EXPO 
Bus 20325 for special operations. . , ^ . . . . ^ ^At^u 

Operand data is provided to MULTIN Bus 20354 through MULTIM 20328, v^rfiich is a dual input, 64 bit 
multiplexer. A first input of MULTIM 20328 is provided from OPO Bus 20323 and is compnsed of operand 
information provided from OPB 20322, OPQ Bus 20323 is a 56 bit wide bus and operand data appearing 
thereon may be comprised of 32 bit integer operands; 32 brt packed dedmal operand^ eWier provided 
directly from OPB 20322 or as a result of OPB 20322's conversion of an unpacked dedmal to a packed 
dedmal operand; 24 bit single precision operand mantissa fields; or 56 bit double precision floating point 
operand mantissa fields. As previously described, certain OPQ Bus 20323 may be zero or sign extension 
filled, depending upon the particular operand. 

Second Input of MULTIM 20328 is provided from MULTRF 20350. MULTRF 20350 is a 16 word by 64 bit 
wide random access memory. As indicated in Figs. 203 and 257, MULTRF 20350 Is connected between 
output of RFR 20336, tiirough FR Bus 20337, and to input of MULT 20314's aritfimetic operation logic 
tfirough MULTIM 20328 and MULTIN Bus 20354. MULTRF 20350 may therefore be utilized as a scratch pad 
memory for storing intermediate results of arithmetic operations, induding 
operations. In addition, a portion of MULTRF 20350 is utilized, as in GRF 10354, as an EU 10122 Stack 
Medianism similarto MIS 10358 and MOS 10370 in FU 10120. Operation of EU 10122 Stack Mechamsrn 
be described in a following descripion of EU 10122's interfaces to MEI^ ^^^^l.^''^^ ^^^Zfr 
Inputs <ADR) of MULTRF 20350 are provided from Multiplier Register File Address Multiplexer 
<MULTRFAM) 25712. 
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MULTRFAM 25712 is a dual four bh multiplexer comprised, for example, of SM74S258^ In addition to 
address inputs to MULTRF 20350, MULTRFAM 25712 provide address mputs to EXPRF 20380. as 
previouslY described. MULTRF 20350 and EXPRF 20380 together comprise an EU 10122 general register Tiie 
shelter to GRF 10354 and FU 10120. As such, MULTRF 20350 and EXPRF 20380 are addre^ed i" Para^^el to 
readind write parallel entriesfrom and to MULTRF 20350 and EXPRF20380.^ 
25712 are provided, first from outputs of mCRD 20346, thus providing "^icrom^uction 
addres^^ of MULTOF ^350 and EXPRF 20380. Second address input to MULTRFAM 25712 ts provided 
from output of Multiplier Register Rie Address Counter (MULTRFACl 25714 

• MULTRFAC 25714 is a four Wt counter and is used to generate sequential addresses to MULTRF 2a3bu 
and EXPRF 20380. Initial addresses are loaded into MULTRFAC 25714 from Multiplier Register Rie Addre^ 
Counter Multiplexer (MULTRFACM) 25716. MULTHFACM 25716 is a dual four bit multiplexer '"P^ ^ 
MULTRFACM 25716 are provided, finrt, from outputs of mCRD 20346. This Input a"^^"^^^^.^*"^^?^^^ 
selection of an Initial address to be loaded into MULTRFAC 25714 to be «"bsequenthr us^and 
sequential MULTRF 20350 and EXPRF 20380 addresses. Second address input to MULTRFACM 25716 is 
provided from OPQ Bus 20323. MULTHFACM 25716's input from OPQ Bus 20323 allows a single addr^. or 
a starting address of a sequence of addresses, to be selected through JPD Bus 10142 or MOD Bus 10144, for 
example from MEM 10112 or FU lOia). ^ ^ .^^ . 

Intermediate and final result outputs of MULT 20314 arithmetic logic P^vWed to data »npute ^ 
MULTRF 20350 directly from FR Bus 20337 and from MULTRM 20334. Inputs to MULTRM 20334, In tum, are 
provided from FR Bus 20^ and from output of CONSCE 20352 and TSTINT »m 

FR Bus 20337 is a 64 bit bus connected from 64 Wt output of RFR 20336 and cames final and 
intermediate results of MULT 20314 arithmetic operations. As wiU become apparent in a Allowing 
description of MULT 20314 arithmetic operation logic, RFR 20336 output, and thus FR Bus ^^'^^t^^!^ 
wide. Sixty-four bits are provided to insure retention of all significant data bits of certoin MULT 20314 
arithmetic operation Intemiediate results, in particular operations involving double precision floa^ point 
64 bit mantissa fields. In addition, as will be described momentarily and has been previously stated, MULT 
20314 may convert a final result in pacted dedma! format Into a final result in unpacked deamal formatin 
this operation, a angle 32 bit, or one word, packed decimal result is converted into a 64 bit or two word. 

unpacked decimal format by insertion of zone fields, nivm 

As described above, two parallel data paths are provided to transfer information from FR Bus 20337 
into MULTRF 20350. First path is directly from FR Bus 20337 and second path is through Unpacked Deamal 
Multiplexer (UPDM) 25718 of MULTRM 20334. Direct path is utilized for tiiirty-two bits of information 
comprising bits 0 to 23 and bits 56 to 63 of FR Bus 20337. Data patii through UPDM 25718 may compnse 
eitiier bits 24 to 55 of FR Bus 20337, which are connected into a first input of UPDM 25718, or bits 40 
through 55 which are connected to a second input of UPDM 257^B. Single precision floating Po^nJ numbers 
are 32 bit numbers plus two or more guard bits and are thus written into MULTRF 20350 throui^ bits 0 to 23 
of the direct path into MULTRF 20350 and through first input {bits 24 to 55) of UPDM ^18, Double 
predion floating point numbers are 5 bhs wide, plus guard bits, end thus utilize tiw dired path into 
MULTRF 20350 and tfie patii tiirough first input of UPDM 25718, Bits 66 to 63 of direct path are utilized for 
guard bits of double precision floating point numbers. Botii integer and packed decimal """^^^J^.V^iSt 
bits 24 through 55 of FR Bus 20337, and are tiius written into MULTRF 20350 through first input of UPDM 
2571& As previously described, bits 0 to 23 of these operands are filled by sign extension. 



a^.a. Container Size Check ^ . 

As stated above, MULTRM 20334 has an Input from CONSCE 20352. As will be descnbed below v«th 
reference to TSTINT 20320, C0NSI2E 20352 performs a "container size" check upon each store back of 
results from EU 10122 to MEM 101 12. CONSIZE 20352 comparesthenumber of significant bits m a result to 
be stored back to the logical descriptor describing tiie MEM 101 12 address space tiiat result "is to be v>fntten 
into. Where feiteiative write operations to MEM 101 12 are required to transfer a result into MEM 101 1 2, that 
is a string transfer, container size Information may read from CONSIZE 20352 through Container Siro Driver 
(CONSEED) 25720 and MULTRM 20334 and written into MULTRF 20^ This allows EU 10122, using 
container to information stored in MULTRM 20350, to perform continuous container size checking dunng 
a string transfer of result from EU 10122 to MEM 10112. In addition, as will be described momentarily, 
container size Information may be read from CONSIZE 20352 to JPD Bus 10144. 



b.b.b. Final Result Output Multiplexer 20324 . 
Referring finally to FROM 20324. as previously described FROM 20324 is utilized to ^"sfw, 'n general, 
resu£TEU^oT^^^ operations onto JPD Bus 10142 for transfer to MEM 10^2 or^^ 10120. As 

in^^Tted in Fig. 257, FROM 20324 is comprised of 24 bit Final R^»t Bus Drtver <P«BD)257^^^^ 
Bus Driver (RBR) 25724. Input of FRBD 25722 is connected from FR Bus 2^ and aHows *Jat8 appearing 
thereon to be transferred onto JPD Bus 1014Z In particular. FRBD »722 ^^1^^ 
mantissa fields of single precision floating point results onto Bus 

corresponding exponent field from EXP 20316. RBR 25724 input is connected from RSLT Bus 20388 to allow 
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output of UPDM 25718 to be transferred onto JPD Bus 10142. RBR 25724, RSLT Bus 20388, and UPDM 
25718 are used, m general, to transfer final results of EU 10122 operations from output of MULT 20314 onto 
JPD Bus 10142. Rnal results transferred by this data path include integer, padced and unpaclced decimal 
results, and mantissa fields of double precision floating point results. Both unpadced decimal numbers and 
s mantissa fields of double precision floating point numbers are comprised of two 32 bit words and are thus 
transferred onto JPD Bus 10142 in two sequential transfer operations. 

Having described structure and operation of MULT 20314's memory elements and input and output 
circuitry, MULT 20314's arithmetic operation logic will be described next below. 

^0 4. Test and Interface Logic 20320 (Rgs. 260—258) 

As previously described, TSTINT 20320 includes CONSIZE 20352, ECPT 20328, TSTCOND 20384, and 
IISTTRPT 2038& CONSIZE 20352. as preN^ously described, performs "container size" check operations when 
results of EU 10122 operations are to be written into MEM 10112. That is, CONSIZE 20352 compares dze or 
number of signiflcam bits, of an EU 10122 result to the capacity, or container size, of the MEM 10112 
fs location that EU 10122 result is to be written into. As indicated. In Fig. 203, CONSIZE 20352 receives a first 
input, that is the results of EU 10122 operations, from FR Bus 20337. A second input of CONSIZE 203£% is 
connected to LENGTH Bus 20226 to recehre length field of logical descriptors identifying MEM 10112 
address space into which those EU 10122 results are to be written. CONSIZE 20352 includes logic circuitry, 
for example a combination of Read Only Memory and Field Programmable Logic Arrays* for examining EU 
20 10122 operation results appearing on i=R Bus 20337 and determining the number of bits of data In those 
results. CONSIZE 20^ compares EU 10122 result size to logical descriptor length field and, in particular. If 
result size exceeds logical descriptor length, provides an alarm output to ECPT 20328, described below. 

TSTCOND 20384, previously described and which will be described further below, Is an interfece circuit 
between PU 101^ and EU 10122. TSTCOND 20384 allows FU 10120 to specify and examine results of 
2S certain test operations performed by EU 10122 with respect to EU 10122 operations. 

ECPT 20328 monitors certain EU 10122 operations and provides outputs indicating when certain 
"exceptions" have occurred. These exceptions include attempted divisions by zero, floating point mponent 
underflow or overflow, mid integer container size fault 

INTRFT 20388 is again an interface between EU 10122 and FU 10120 allowing FU 10120 to intemipt EU 
30 10122 operations. INTRPT 20388 allows FU 101 20 to cfirect EU 10122 to execute certain operations to aid in 
handling of certain FU 10120 events premusly described. 

Operation of CONSIZE 233S1. ECPT 20328, TSTCOND 20384, INTRPT 20388, and Other features of EU 
10122*8 irtterface with FU 10120 will be described further below in the following description of operation of 
that interface and of operation of .certain EU 10122 internal mechanics, such as FU 10120 Stack 
35 Mechanisms. 

a.a. FU 10120€U 10122 Interface 
As previously described, EU 10122 and FU 10120 are asychronous processors, each operating under its 
own microcode control. EU 10122 and FU 10120 operate simultaneousty and independ^y of each other 
40 but are coupled, and their operations coordinated, by interface signals described below. Should EU 10122 
not be able to respond immediately to a request from FU 10120, FU 10120 will idle until EU 10122 becomes 
available; conversely, should EU 10122 not receive, or have present, operands or a request for operations 
from FU 10120, EU 10122 will remain in idle state until operands and requests for <H)arations are received 
from FU 10120. 

4ff in normal operation, EU 10122 manipulates operands under control of FU 1 0120, which in tum is under 
control of SOPs of a user's program. When FU 10120 requires arithm^c or logical manipulation of an 
operand, FU 10120 dispatches a command, that is an Execute Unit Dispatch Pointer (EUDP) to EU 10122. As 
previously described, an EUDP is basically an initial address Into EUSITT 20344. An EUDP identifies starting 
location of a EU 10122 microinstruction sequence performing the required operation upon operands. 

SO Operands are fetched from MEM 10112 under FU 10120 control, as previously described, and are 
transferred Into OPB 20322. Those operands are then called from OPB 20322 by EU 10122 and transferred 
into MULT 20314 and EXP 20316 as pre\dously described. After the required operation Is completed, FU 
10120 IS notified that a result is ready. At this point, FU 10120 may check certain test conditions, for 
example through TSTCOND 20384, such as whether an integer or decimal carry bit is set or whether a 

ss mantissa sign bit is set or reset. This test operation is utilized by FU 10120 for conditional branching and 
synchronization of FU 10120 and EU 10122 operations. Exception checking, by ECPT 20328, Is also 
performed at this time. Exception checking determines, for example, whether division by zero was 
attempted or if a container size fault has occurred, ^n general, FU 10120 is not informed of exception errors 
until FU 10120 requests exception checking. After results are transferred Into FU 10120 or MEM 10112 by 

60 EU 10122, EU 10122 goes to idle operation until a next operation is requested by FU 10120. 

Having briefly described overall interfece operation between FU 1 0120 and EU 1 0122, operation of that 
interfisce, referred to as handshaldng, will be described in greater detail next below. In general, 
handshaking operation between EU 10122 and FU 10120 during normal operation may be regarded as 
following into six operations. These operations may include, for example, loading of COMQ 20342. loading 

«s of OPB 20322, storeback or transfer of results from EU 10122 to FU 10120 or MEM 10112, check of test 
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conditions, exception checking, and EU 10122 idle operation. H!n<*^|^^';^^^^^^ SeJ^^^o"""^ 
10122 will be described below for each of these classes of operabon. In the order Just referred to. 

a.a.a. Loading of Command Queue 20342 (Rg. 260) .^^^.r^^nryt 

Referring to Fig. 260, a schematic representation of EU 10122's interface wrth FU 10120 for PurPOses of 
loading COMQ 20342 as shown. During normal SOP directed JP 101 14 operation. 8 bit operation <OP) codes 
are pareed from the instruction stream, as previously described, and concatenated with dialed ^"^on^fon 
to address EUSOT 20268 also as previously described EUSDT 20266 provides corresponding addresses, 
that is EUOPs. to EUSrrr 20344. ^ ^ . *u^«.«..««f 

Dialect information specifies the S-Language currently being executed and. consequently the Q^oupoX 
microinstruction sequences available in EUSITT 20344 for that S-Language. As previously descnbed, FU 
10120 may spedfyfour S-Language dialects with up to 256 EU 10122 microinstruction sequences per 
ctialect. or 8 dialects with up to 128 microinstruction sequences per dialect. 

EUDPS provided by EUSDT 20266 are comprised of a 9 bit address field, a 2 bit operand information 
field, and a 1 bH flag field, as previously described. Address field is starting address of a micromstru^ion^ 
seauence in EUSITT 20344 and EU 10122 will perform the operation directed by that micromstructton 
sequence. EUSITT 20344 requires 1 1 bits of address field and the 9 bit address field of EUDPs are mapped 
into an 11 bit address field by left justification and zero filling. 

FU 10120 may also dispatch, or select, any EU 10122 microinstruction controlled operaton from jpd 
B^is 10142. Such EUDPs are provided from JPD Bus 10142 to daU input of EUSITT 20344 and passed 
directiy through to mCRD 20346. Before a EUDP may be provided from JPD Bus '^^^f}r}l^^^^'^J' ^ ^^^^O 
provides a check operation comparing that EUDP to a list of legal, or ^"owed^^^SnT 203^ 
stored in MEM lOlli Afault will be indicated if an EUDP provided through Bi^l0142 is nm a 1^^^^ 
EUSITT 20344 address. Alternately, FU 10120 may effectively provide an EUDP, or EUSITT 20344 
addresses, from a riteral field in a FU 10120 microinslnictioh word. Such a FU 10120 microinstruction word 
literal field may be effectively utilized as an SOP into EUSDT 202^. 

Handshaking between EU 10122 and FU 10120 during toad COMQ 20342 operations may proceed as 
illustrated in Fig. 26a A tweNe bit EUDP may be placed on EUDIS Bus 20206 and Coritrol Signal Uad 
Command Queue (LDCMQ) asserted. If COMO 20342 is full, EU 10122 raises control signal C^mnr^d Hold 
<CMDHOLD) which causes FU 10120 to remain in State MO until tiiere is room in COMQ 2^. 
oreviouslv described, COMQ 20342 is COTiprised of two, two word buffers wherein one buffer ts utiloed for 
normal SOP operation and the other utifized for control of FU 10120 and EU 10122 internal mechanism 

operation^ are loaded into COMQ 20342 when state timing signals M1CPT and Ml are asserted. If a EUDP 
beinq transferred into COMQ 203« concerns a double precision floating point operation, control signal Set 
Double Precision (SETDP) fe asserted. SETDP Is utilized to control OPB 20322, and because single pieasion 
and precision floating point operations otherwise utilize the same SOP and thus would otiienwise refer to 
same EUSITT 20344 microir»tniction sequence. .„ ^ ^ ^ ^ ^ ci i nmoA 

At tills point a EUDP has been loaded into COMQ 20342 and will be decoded to control FU lOm 
operation by EUCL 20310 as previously described. Ea«^ particular EUDP will be cleared by that EUDPs 
EUSITT 20344 microinstruction sequence after the requested microinsiniction sequence has been 
executed. 



b.b.b. Loading of Operand Buffer 20320 (Rg« 261 ) 

Referring to Fig. 261, a diagramic representation of tf^ interface and handshaking between EU 10122, 
FU 10120 and MEM 101 12 for loading OPB 20322 is shown. Control signal Qear Queue Full (CLQF} from EU 
1 01 22 must be asserted by EU 101 22 before FU 1 01 20 initiates a request to MEM 101 12 for an operand to be 
transferred to EU 10122. CLQF clears and "EU 10122's OPB 20322 Full" condition in FU 10120. CLQF 
indicates, thereby, that there is room in OPB 20322 to receive operands. If FU 10120 is in a "EU 10122's OPB 
20322 Full" condition and furtfier operand is required to be transferred to EU 10122, FU 10120 will remain in 
State Ml until CLQF is asserted. 

At the beginning of execution of a particular SOP, FU 10120 may transfer two operands to OPB 20322 
without "EU 10122's OPB 20322 Full" condition occurring. This is because EU 10122 is idle at the beginning 
of an SOP execution and generally immediately unloads a first operand from OPB 20322 before a second 
operand arrives. ^ . . 

Control signal Job Processor Operand (JPOP) provided from FU 10120 must be non-asserted for 
operands to be transferred from MEM 10112 to OPB 20322 tiirough MOD Bus 10144. This is the normal 
condition of JPOP. If JPOP is asserted, OPB 20322 is loaded whh data from JPD Bus 10142. Data is strobed 
into OPB 20322 from JPD Bus 1 0142 by control signals M1CPT and JPOP. Operands read from MEM 10112, 
hov^rever, are transferred into OPB 20322 tiirough MOD Bus 10144 when MEM 10112 asserts DAVEB to 
indicate tiiat valid data from MEM 10112 is available on MOO Bus 10144. DAVEB is also utilized to strobe 
data on MOD Bus 10144 into OPB 20322. If control signal ZFILL from MEM 101 12 is asserted at this point 
ZRLL is interpreted during integer operand operations to indicate that those operands are unsigned and 
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should be left zero filled, rather than sign extended. If data is being provided from JPD Bus 10142 rather 

than from MEM 10112, that is if JPOP Is asserted, bit 11 of current EUDP may be utilized to perform the 

same function as ZRLL during loading of OPB 20322 from MOD Bus 10144. 

Loading of OPB 20322 is controlled, in part, by bits S and 10 of EUDPs provided from FU 1 01 20 through 
s EUWS Bus 20206. Bit 9 indicates length of a first operand while bit 10 Indicates length of a second operand. 

Operand length, together with operand type specified in address portion of a EUDP, detemnmes how a 

particular operand is unloaded from OPB 20322 and transferred into MULT 20314 and EXP 20316. 
AX this point both COMQ 20342 and OPB 20322 have been loaded with, respectively, EUDPs and 

operands. It should be noted that operands are generally not transferred into OPB 20322 before a 
« corresponding EUDP is loaded into COMQ 20342. Operands and EUDPs may. however, be simultaneously 

transferred into EU 10122. tf other operands are required for a particular operation, those operands are 

loaded into OPB 20322 as d^ribed above. 



js ccc Storeback (fig. 262) 

Referring to Fig. 262. a diagramic representation of a storeback, or transfer, of results to MEM 10112 

from EU 1 01 22 and handshaking performed therein is shown- When a final result of a EU 10122 operation is 

available, EU 10122 asserts control signal Data Ready (ORDY). FU 10120 thereupon responds with control 

signal Transfer to JPD Bus 10142 (XJPD), which gates EU 10122's result onto JPD Bus 10142. In normal 
20 operation, that is execution of SOPs, FU 1 0120 causes EU 1 01 22's resuH to be stored back into a destination 

in MEM 10112, as selected by a physical descriptor provided from FU 10120. Altemately, a result may be 

transferred into FU 10120, 32 bits, or one word, at a time. 

FU 1 0120 may, as described above and described further below, check EU 1 0122 test conditions during 

storeback of results* FU 10120 generates control signal Transfer Complete (XFRC) once the storeba<* 
25 operation is completed. XFRC also indicates to EU 10122 that EU 10122's results and test conditions have 

been accepted by FU 10120, so that EU 10122 need no longer assert these results and test conditions. 

d.d.d. Test Conditions (Rg. 263) 
Referring to Fig. 263, a diagramic representation of cheddng of EU10122 test conditions by FU 10120, 

30 and handshaking therein, is shown. As previously descrik>ed, test results Indicating certain conditions and 
operations of EU 10122 are sampled and stored in TSTCOND 20384 and may be examined by FU 10120. 
When DRDY is asserted by EU 10122, FU 10120 may select, for example, one of 8 EU 10122 conditions to 
test, as well as transferring results as described above. EU 10122 conditions which may be tested by FU 
10120 are listed and described below. Such conditions, as whether a final result is positive, negative, or 

35 zero, may be checked in order to facilitate conditional brandling of FU 10120 operations as previously 
described. FU 1 0120 specifies a condition to be tested through Test Condition Select signals {TEST(24)), FU 
10120 asserts control signal EU Test Enable (EUTESTEN) to EU 10122 to gate the selected test condition. 
That selected test contfitlon then appears as Data Signal Test Condition fTC) from EU 10122 to FU 10120. A 
TC of logic 1 may, for example, indicate that the selected condition is false while a TC of logic O may 

40 indicate that the selected condition is true. FU 1 0120 Indicates that FU 1 0120 has sensed the requested test 
condition, and that the test condition need no longer be asserted by EU 10122, by asserting control signal 
XFRC. 



4S e.e.e. Exception Checking <Rg. 264) ^. w nn 

Referring to Rg. 264, a diagramic representation of exception checkmg of EU 10122 exceptions by PU 
10120, and handshaking therein, is shown. As previously described, any EU 10122 exception conditions 
may be checked by FU 10120 as FU 10120 is initiating storeback of EU 10122 results. Exception checking 
may detect, for example, attempted division by zero, floating point exponent underflow or overflow, or a 

so container size fault An attempted division by zero or floating point underflow or overflow may be checked 
before storebadc that Is without specific request by FU 10120. . . u ^ 

As prwiously described, a container me fault is detected by CONSIZE 20352 by companng length of 
result size of destination container in MEM 10112. Container size exception checking occurs during 
store back of EU 10122 results, that is while FU 10120 is In State SB. Container size is automatically 

ss performed by EU 10122 hardvwre, that is by CONSIZE 20352, only on results of less than 33 bits length. Size 
dieddng of larger results, that is larger integers and BCD results, is performed by a microcode rout ne, 
using CONSIZE 20352's output, as transfer of such larger results Is executed as stnng transfer. It is 
unna:essarY to perform container size check for either single or double precision floating point results as 
these data types always occupy either 32 or 64 bits. Destination container size is provided to CONSIZE 

60 20352 through LENGTH Bus 20226. ^ x 

Control signal Length to Memory AON or Random Signals (LMAONRS) is general^ ^y FU 10120 from 
Type field of the logical descriptor corresponding to a particular EU 10122 result. LWAONRS indicates that 
the results data type is an unsigned integer. LMAONRS determines tiie manner m w^'di a required 
container size of tfie EU 10122 result is determined. After recelvng this information from LMAONRS, EU 

& 10122 determines whether destination container size in MEM 101 12 is sufRcientiy large to contain the EU 
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10122 result tf that destination container size is not suffictentty large« a container size fault is detected by 
CONSIZE 20352, or through an EU 10122 microinstruction sequence. 

Container ^e faults, as well as division by zero and exponent underflow and overflow faults, are 
signaled to RJ 10120 when FU 10120 asserts control signal Check Size (CKSIZE). At this time. EU 10122 
s asserts control signal Exception (EXCPT) If any of the above faults has occurred, if a fault has occurred, an 
Event request to FU 101 20 results. When an Event request Is honored by RJ 10120, FU 10120 may interrupt 
EU 10122 and dispatch EU 10122 to a microinstruction routine that transfers those exception conditions 
onto JPD Bus 10142. If a container size fault has caused that exception condition, EU 10122 may transfer to 
FU 10120 the required container size through JPD Bus 10142. 

70 

f.f.f. Idle Routine 

Rnally, when a current EU 10122 operation is completed, EU 10122 goes into an Idle loop 
microinstnjction routine. If necessary, FU 10120 may assert control signal Excute Unit Abort (EU ABORT) to 
75 force EU 10122 into Idle loop microinstruction routine until EU 10122 is required for further operations. 



g^.g. EU 10122 Stack Mechanism (Rgs. 26S, 266, 267) 
As previously described, EU 10122 may perform either of two classes of operations. Rrst, EU 10122 
20 may perform arithmetic operations in execution of SOPs of user's programs. Second, EU 10122 may 
operate as an arithmetic calculator assisting operation of FU 10120'$ internal mechanisms and operations, 
referred to as kernel operations. 

in kernel operation, EU 10122 acts as an arithmetic catcuiatorfor FU 10120 during address generation, 
address translation, and other kernel functior^. In kernel mode, EU 10122 is executing microinstruction 
25 sequences at request of FU 10120 kernel microinstruction sequences, rather than at request of an SOP. In 
general, these kernel operations are vital to operation of JP 10114. FU 10120 may interrupt EU 10122 
operations with regard to SOPs and initiate EU 10122 microinstruction sequences to perform kamel 
operations. 

When Interrupted, EU 10122 saves EU 10122*$ current operating ^ate in a one level deep stack. EU 

30 10122 may then accept an EUDP from that portion of COMQ 20342 atifized to recehre and store EUDPs 
regarding FU 10120*$ and EU 10122's internal, or kernel, operations. When requesting kernel operations by 
EU 10122, FU 10120 generally transfers operands to OPS 20322 through JPD Bus 10142, and reoraves EU 
10122 final results through JPD Bus 10142. Operands may also be provided to EU 10122 through MOD Bus 
10144. After EU 10122 has completed a requested kernel operation, EU 10122 reloads operating state from 

3$ its internal stack and continues normal o|>eration from the point normal operation was interrupted. 

Should another interrupt from FU 10120 occur while a prior interrupt is being executed, EU 10122 
mcntes current state and data, that Is of first interrupt* to MEM 10112. EU 10122 requests FU 10120 store 
state and date of first interrupt in MEM 10112 by requesting an "EU 10122 Stack Overflow" Event. EU 
10122's ''nornial" state, that is state and data pertaining to the operation EU 10122 is executing at time of 

40 occurrence of first interrupt, is stored in an BJ 10122 intemal stack and remains there. EU 10122 then 
begins executing second intemipt When EU 10122 has completed operations for second Interrupt, state 
from first intemipt is reloaded from MEM 10112 by EU 10122 requesting a ''EU 10122 Stack Underflow" 
Event to FU 10120*. EU 10122 then completes execution of first interrupt and reloads state and resumes 
execution of normal operation, that is the operation bdng executed before the first interrupt 

45 EU 10122 is therefore capable of handling interrupts from FU 10120 during two circumstances. First 

interrupt circumstance is comprised of interrupts occurring during normal operation, that Is while 
executing SOPs of user's programs. Second circumstance arises when interrupts occur during kernel 
operations, that Is during ^ecution of microinstruction sequences for handling interrupts. EU 10122 
operation will be described next t>elow for each of these circumstances, and in the order referred to. 

so Referring to Rg. 265, a diagramic representation of EU 10122's stack mechanisms, previously 

described, is shown. Those portions of EU 10122's stack mechanisms residing within EU 10122 are 
comprised of EU 10122's Current State Registers (EUCSRs) 26510 and EU 10122's Internal Stack <EU1S} 
26512. EUCSR 26510 is comprised of EU 10122's internal registers which contain data and state of current 
EU 10122 operation. EUCSR 26510 may be comprised, for example, of mCRD 20346, registers of TSTINT 

ss 20320, and the previously described registers within MULT 20314 and EXP 20316. 

State and data contained in EUCSR 2^10 is that of the operation currently being executed by EU 
10122. This current state may, for example, be that of a SOP curnentiy being executed t}y EU 10122, or that 
of an interrupt, for example a fourth interrupt of a nested sequence of interrupts, requested by FU 10120. 
EUlS 2^12 is comprised of certain registers of MULTRF 20350 and EXPRF 20380. EUiS 2^12 is utilized 

0Q to store and save current state of an SOP operation currentiy being executed by EU 10122 and which has 
been interrupted. State and data of that SOP operation will remain stored in EUIS 26512 regardless of the 
number of interrupts which may occur on a nested sequence of interrupts requested by FU 10120. State 
and data of the interrupted SOP operation will be returned from EUIS 26512 to EUCSR 26510 when all 
interrupts have been completed. 

^ Final portion of EU 10122'$ stack ntechanism is that portion of EU 10122's intemal stack (EUES) 26514 
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residing in MEM 10112. EUES 26514 is comprised of certain MEM 10112 address locations used to store 
state and data of successive interrupt operations of sequences of nested interrupts. That is# if a sequence of 
four interrupts is requested by FU 10120, state and data of fourth irrterrupt will reside in EUCSR 26510 while 
state and data of first, second, and third interrupts have been transferred, in sequence. Into EUES 26514. In 

5 ' * this respect and as previously described operation of EU 10122*8 stack mechanisnns is similar to that of, for 
example, MIS 10368 and SS 10336 previously described with reference to Rg. 103. 

As described above, an intermpt may be requested of EU 10122 by FU 10120 either during EU 10122 
normal operation, that is during execution of SOPs by EU 10122, or while EU 10122 is executing a previous 
interrupt requested by FU 10120. Operation of EU 10122 and FU 10120 upon occurrence of an interrupt 

10 during EU 10122 normal operation will be described next below. 

Referring to Rg. 266, a diagramic representation of handshaking between EU 10122 and FU 10120 
during an interrupt of EU 10122 while EU 101221s operating in normal mode is showm and should be 
referred to in conjunction with Fig. 265. For purposes of the following discussions, interrupts of EU 10122 
operattons by FU 10120 are referred to as nanointerrupts to distinguish from interrupts internal to FU 

« 10120. 

FU 10120 interrupts normal operation of EU 10122 by assertion of control signal Nano-lnterrupt 
ININTP] during State MO of FU 10120 operation. NINTP may be masked by £U 10122 during certain critical 
EU 10122 operations, such as arithmetic operations. If NINTP is masked by EU 10122, FU 10120 vidll remain 
in State NW until EU 10122 acknowledges the interrupt 

20 Upon receiving Nll^ from FU 10120, EU 10122s transfers state and data of current SOP operation 
from EUCSR 26510 to EUrS 26512. EU 10122 then asserts control signal Nano-lnterrupt Acknowledge 
(NtACK) to FU 10120 to acknowledge availability of EU 10122 to accept a nanolnterrupL FU 10120 will then 
enter State Ml and place an EUDP on EUDIS Bus 20206. Loading of COMQ 20342 then proceeds as 
previously described, with EU 10122 loading nanointerrupt EUDPs into the appropriate registers of COMQ 

25 20342. COMQ 20342 is loaded as previously described and, if JPOP is asserted, data transferred into OPB 
20322 from JPO Bus 10142. If JPOP is not asserted, data is taken into OPB 20322 from MOD Bus 10144. EU 
10122 then proceeds to execute the required nanointerrupt operation and storing back of results and 
checking of test conditions proceeds as previously described for EU 10122 normal operation. In general, 
exception checking is not performed. When EU 10122 has completed execution of the nanointerrupt 

so operation, EU 10122 transfers state and data of the interrupted SOP operation from EUlS 26512 to EUCSR 
26510 and resumes execution of that SOP. At this point, EU 10122 asserts control signal Nano-tnterrupt 
Trap Enable (NITE). NUE is rec^ved and tested by FU 10120 to indicate end of nanointerrupt processing. 

Referring to Rg. 267, a cfiagramic representation of Interfiaces between EU 10122, FU 10120, and MEM 
10112 during nested, or sequential, EU 10122 interrupts for kernel operations, and handshaking therein. Is 

35 shown. During tiie following discussion, it is assumed that EU 10122 Is already processing a nanointerrupt 
for a kernel operation submitted to EU 10122 by FU 10120. FU 10120 may then submit a second, third, or 
fourth, nanointemipt to EU 10122 for a further kernel operation. FU 10120 will assert NINTP to request a 
nanoimerrupt of EU 10122. EU 1012rs normal mode state and data from a previously executing SOP 
operation has been stored in. and remains In, EUlS 26512. Currem state and data of currentiy executing 
nanointemjpt operation In EUCSR 26510 will be transferred to EUES 26514 in MEM 101 12 to allow initiation 
of pending nanointerrupt EU 10122 will at this time assert NIACK and control signal Execute Unit Event 
JEXEVT). EXEVT to FU 10120 informs FU 10120 that an EU 10122 Event has occunred, spedflcaliy, and in 
this case, EXEVT requests FU 10120 sendee of an EU 10122 Stack Overflow. FU 10120 is thereby trapped to 
an "EU 10122 Stack Overflow" Event Handler microinstruction sequence. This handier transfers currem 

4$ state and data of interrupted nanointerrupt previously executing in EU 10122 into EUES 26514. State and 
data of interrupted nanointerrupt is transferred to EUES 2^14, one 32 bit word at a time. FU 10120 asserts 
control »*gnais XJR) to gate each of these state and data words onto JPD Bus 10142 and controls transfer 
of these words into EUES 26514. 

Processing of new nanointerrupt proceeds as described above with reference to imerrupts occurring 

50 during normal operation. If any subsequem nanointerrupts occur, they are handled In the same manner as 
just described; FU 10120 signals a nanointerrupt to FU 10120, current EU 10122 state and data is saved by 
FU 10120 in EUES 2K14, and new nanointemipt is processed. After a nested nanointerrupt, that is a 
nanointemjpt of a sequence of nanointeroipts. has been serviced, EU 10122 asserts comrol signal EU 
10122 Trap (ETRAP) to FU 10120 to request a transfer of a previous nanointerrupfs state and data from 

55 EUES 26514 to EUCSR 26510. FU 10120 wil 1 retrieve that next previous nanointerrupt state and data from 
EUES 26514 through MOD Bus 10144 and will transfer that data and state onto JPD Bus 10142. This state 
and data is returned, one 32 bit word at a time, and is strobed into EU 10122 by JPOP from FU 10120. 
Processing of that prior nanointerrupt will then resume. The servicing of successively prior nanointerrupts 
will continue until all previous nanointerrupts have been serviced. Original state and data of EU 10122, that 

eo is that of SOP operation which was initially inten-upted, is then returned to EUCSR 26510 from EUlS 26512 
and execution of that SOP resumed. At this time, EU 10122 asserts NITE to indicate end of EU 10122 kernel 
operations in regard to nanointerrupts. 

Having described structure and operation of EU 10122, FU 10120 and MEM 10112, with respect to 
servicing of kernel operation nanointerrupts by EU 10122, loading of EU 10122's EUSITT 20344 whh 

s$ microinstmction sequences will be described next below. 
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h.h.h.h Loading of Execute Unit S-lnterpreter Table 20344 (Rg, 268) 
Referring to Rg. 268, a diagramic representation of interface and handshaking between EU 10122, FU 
1D120. MEM 10112, and DP 10118 during loading of microinstructions Into EUSITT 2)344 is shown. As 
previously descritwd, EUSHT 20344 contains aii microinstructions required for control of Ell 10122 In 

5 executing Icemel nanointerrupt operations end in executing arithmetic operations in response to SOPs of 
user's programs, EUSiTT 20344 may store microinstruction sequences for interpreting arithmetic SOPs of 
user's programs for, for example, up to 4 different S-Language Dialects. In general, a capacity of storing 
microinstruction ^uenc^ for arithmetic operations In up to 4 S-language Dialects is sufficient for most 
requirements, so that EUSITT 20344 need be loaded with microinstruction sequences only at initialization 

to of CS 10110 operation. Should microinstruction sequences for arithmetic operations of more than 4 S- 
Language Dialects be required, those microinstruction sequences may be loaded into EUSITT 20344 in the 
manner as will be described below. 

As previously described, a portion of the microinstructions stored in EUSITT 20344 is contamed m 
Read Only Memories and is thus pcrmanentiy stored in EUSITT 20344. Microinstruction sequences 

IS permanentiy ^ored m EUSITT 20344 are, in general, those required for execution of kernel operations. 
Microinstnjc^on sequences permanentiy stored in EUSITT 20344 include those used to assist in writing 
other EU 10122 microinstruction sequences into EUSITT 20344 as required. Certain microinstruction 
sequences are stored in a Random Access Memory, referred to as the Writeable Control Store (WCS) 
portion of EUSITT 20344, and include these for interpreting arithmetic operation SOPs of various S- 

20 Language Dialects. 

Writing of microinstruction sequences Into EU 10122 Is initialized by forcing EU 10122 mto an Idle state. 
Initialization of EU 10122 is accomplished by FU 10120 asserting EUABORT or by DP 10118 asserting 
control agnal dear (CLEAR). Either EUABORT or CLEAR will dear a current operation of EU 101 22 and force 
EU 10122 into Idle state, wherein EU 10122 waits for further EUDPs provided from FU 1012a FU 10120 tiien 

25 dispatches a EUDP initiating loading of EUSITT 20344 to EU 10122 through EUDIS Bus 20206. Load EUSITT 
20344 EUDP spedfies starting address of a two step microinstruction sequence in tiie PROM portion of 
EUSITT 20344. This two step microinstruction sequence first loads zeros Into SCAG 25536, which as 
prevtously described provides read and write addresses to EUSITT 20344. EUSTTT 20344 load 
microlnslitiction sequence then reads a microinstruction from EUSITT 20344 to mCRD 20346. Thfe 

so microinstruction specifies conditions for handshaking operations witii FU 101 20 so that loading of EUSITT 
a)344 may begin. At ttils time, and from this microinstruction word, EU 10122 asserts control signal DRDY 
to FU 10120 to Indtcata tfiat EU 10122 is ready to accept EUDPs from FU 10120 for directing loading of 
EUSITT 20344. This initial microinstruction also generates a write enable control signal for the WCS portion 
of EUSITT 20344, inhibits loading of mCRO 20346 from EUSITT 20344, end inhibits normal loading 

as operations of NXTR 25540 and SCAG 25536. This first microinstruction also directs NASS 25526 to accept 
address inputs from SCAG ^S36 and. finally, causes NITE to FU 10120 to be asserted to unmask 
nanointerrupts from FU 1012a 

FU 10120 then generates a read requedtoMEM 10112«dnd MEM 10112 transfers a first 32 bit word of a 
EU 10122 microinstruction word onto JPD Bus 10142. Each such 32 txt word from MEM 10112 comprises 

40 one half of a 64 bit mk:roInstruetion word of EU 10122. When FU 10120 receives DRDY from EU 10122, FU 
10120 generates control signal Load Writeable Control Store (LDWCS). LDWCS in turn transfers a 32 bit 
word on JPD Bus 10142 into a first address of the WC^ portion of EUSITT 20344. A next 32 bit half word of a 
EU 10122 microinstruction word is then read from MEM 10112 through JPD Bus 10142 and transferred into 
the second half of that first address within the WCS portion of EUSITT 20344. The address in SCAG 25536 is 

45 tlien increntented to select a next address within EUSITT 20344 and the process just described repeated 
automatically, induding generation of TODY and LDWCS, until loading of EUSTTT 20344 is oomfrfeted. 

After loading of EUSITT 20344 is completed, the loading process is terminated when FU 10120 asserts 
NINTP, or DP 10118 asserts Control Signal Load Complete ILOADCRJ; Bther NINTP or LOADCR releases 
control of operation of NAG 20340 to allow EU 10122 to resume normal operation, 

gQ The above descriptions have desoibed structure and operation of EU 10122, including: execution of 
various arithmetic operations utilizing variot^ operand formats; operation of EU 10122, FU 10120, and 
MEM 101 12 v»th regard to handshaking; loading of EUDPs and operands; storeback of results; checking of 
test conditions and exceptions; EU 10122 Stack Mechanisms during normal and kernel operations; and 
loading of EU 10122 mioolnstruction sequences into EUSTTT 20344. lOS 10116 and DP 10118 will be 

gs described next below, in that order. 



D. I/O System 101 16 (Rgs. 204, 206, 269) 

Referring to Rg. 204, a partial block diagram of lOS 101 16 is shown. As previously described, lOS 101 16 
operates as an interface betv\reen CS 10110 and the external worid, for example, ED 10124. A primary 
function of lOS 101 16 is the transfer of data between CS 101 10, that is MEM 10112, and the external worid. 
In addition to performing transfers of data, lOS 10116 controls access bctwewi various data sources and 
sinks of ED 10124 and MEM 10112. As previously d^ribed, IDS 10116 <firectly addresses MEM 10112's 
physical address space to write data into or read data from MEM 10112. As such, lOS 101 16 also pertornts 
address translation, a mapping operation required in transferring data behween MEM 10112's physical 
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address space and address spaces of data sources and sinks in ED 10124. 

As shown in Rg. 204, lOS 101 16 includes Data Mover (DWOVR) 20410, Input/Output Control Processor 
(lOCP) 20412, and one or more data channel devices. lOS 10116's data channel devices may include 
ECLIPSE® Burst Multiplexer Channel (EBMC) 20414, NOVA Data Channel (NDC) 20416, and other data 

s channel devices as required for a particular configuration of a CS 10110 system. IDCP 20412 controls and 
directs transfer of data between MEM 10112 and ED 10124, and controls and directs mapping of addresses 
between ED 1 0124 and MEM 1 01 1 2'& physical address space. lOCP 2041 2 may be comprised, for example, 
of a general purpose computer, such as an ECUPSE<>^ M600 computer available from Data General 
Corporation of Westboro, Massachusetts, 

10 EBMC 20414 and NDC 20416 comprise data channels through which data is transferred between ED 
10124 and ICS 10116. EBMC 20414 and NDC 20416 perform actual transfers of data to and from ED 10124, 
under control of lOCP 20412, and perform mapping of ED 10124 addresses to MEM 10112 physical 
addresses, also under control of lOCP 20412. EBMC 20414 and NDC 20416 may respectively be comprised, 
for example, of an ECUPSE® Burst Multiplexer Data Channel and a NOVA® Data Channel, also available 

^5 from Data General Corporation of Westboro, Massachusetts. 

DMOVR 20410 comprises lOS 10116's interface to MEM 10112. DMOVB 20410 is the path through 
which data and addresses are transferred between EBMC ^14 and NDC 20416 and MEM 10112. 
Additionally, DMOVR 20410 controls access between EBMC 20414, NDC 20416, and other lOS 10116 data 
channels, and MEM 10112. ^ ^ ^r..^-.. 

20 E0 10124, as indicated In Rg, 204, may be comprised of one or more data sinks and sources. ED 10124 
data sinks and sources may Include commerdalty availabte disc drive units, line printers, comnnunication 
lengths, tape units, and other computer systems. Including other CS 1011O systems. In general, ED 10124 
may Include all such data devices as are generally int^aced with a computer system. 

25 

a. UO System 10116 Structure <Hg. 204) 

Referring first to the overall structure of ICS 10116, data Input/output of ECUPSE® Burst Multiplier 
Channel Adapter and Control arcuitrY (BMCAC) 20416 of EBMC 20414 is connected to bl-dfrectlonal BMC 
Address and Data (BMC/^) Bus 20420. BMCAD Bus 20420 in turn is connected to daU and address inputs 

3o and outputs of data sinks and sources of ED 10124. 

Similarly, data and address Inputs end outputs of NOVA^ Data Channel Adapter Control Circuits 
(NDCAC) 20422 in NDC 20416 is connected to bi-directional NOVA® Data Channel Address and Data 
(NDCAD) Bus 20424. NDCAD Bus 20424 in turn is connected to address and data inputs and outputs of data 
sources and sivks of ED 10124. BMCAD Bus 20420 and NDCAD Bus 20424 are paths for transfer of data and 

55 addresses between data sinks and sources of ED 10124 and IDS 10116's data channels and may be 
expanded as requlred:to Include other lOS 10116 data channel devices and other data sink and source 
devices of ED 10124. 

Within EBMC 2041 4, bi-directional data input and output of BMCAC 20418 is connect to bi-dlrectlonal 
input and output of BMC Data Buffer (6MCDB) 2042& Data Inputs and data outputs of BMCDB 20426 are 

40 connected to, respectively. Data Mover Output Data {DMOD) Bus 20428 and Data Mover Input Data (DMID) 
Bus 20430. Address outputs of BMCAC 20418 are connected to address inputs of Burst Multiplexer Channel 
Address Translation Map (BMCATM) 20432 and address outputs of BMCATM 20432 are connected onto 
DMID Bus 20430. A bi-directional control input and output of BMCATM 20432 is connected from bi- 
directional 10 Control Processor Control (lOCPC) Bus 20434. 

45 Referring to NDC 20416, as indicated In Rg. 204 data Inputs and outputs of NDCAC 20422 are 
connected, respe«ively, from DMOD Bus 20428 and to DMID Bus 20430, Address outputs of NDCAC 20422 
are connected to address inputs of NOVA^ Data Channel Address Translation Map (NDCATM) 20436. 
Address outputs of NDCATM 20436 are, in turn, connected onto DMID Bus 20430. A bi-directionai control 
input and output of NDCATM 20436 is connected from lOCPC Bus 20434. 

50 Refemng to lOCP 20412, a bi-directional control input and ou^ut of lOCP 20412 is connected from 
lOCPC Bus 20434. Address and data output of lOCP 20412 is connected to NDCAD Bus 20424. An address 
output of lOCP Address Translation Map (tOCPATM) 20438 within lOCP 20412 is connected onto DMID Bus 
20430. Data inputs and outputs of lOCP 20412 are connectedr respecth^ely, to DMOD Bus 20428 and DMID 
Bus 20430. A bi-directional control Input and output of lOCP 20412 Is connected to a bi-directional control 

55 input and output of DMOVR 20410. 

Refen-ing finally to DMOVR 20410, DMOVR 20410 includes Input Data Buffer (IDS) 20440, Output Data 
Buffer {0D61 20442, and Priority Resolution and Control (PRC) 20444. A data and address input of ID6 20440 
is connected from DMID Bus 20430. A data and address output of IDB 20440 is connected to lOM Bus 10130 
to MEM 10112. A data output of ODB 20442 is connected from MIO Bus 10129 from MEM 10112, and a data 

60 output of ODB 20442 is connected to DMOD Bus 20428. Bi-directional control inputs and outputs of lOB 
20440 and ODB 20442 are connected from bi-directional control inputs and outputs of PRC 20444. A bi- 
directional control input and output of PRC 20444 is connected from a bi-directional control input and 
ou^ut of lOCP 20412 as described above. Another bl-direalonal control input and output of PRC 20444 is 
connected to and from lOMC Bus 10131 and thus from a control input and output of MEM 10112. Having 

^ de^ribed overall structure of lOS 10116, operation of lOS 10116 will be described next below. 
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b. I/O System 10116 Operation (Rg. 269) 

1. Data Channel Devices cn ♦i>r«..«h 

Referring first to EBMC 20414, BMCAC 20418 receives data and addresses from ED 10124 through 
BMCAD Bus 2042a BMCAC 20418 transfers data into BMCDB 20426, where that data is held for subsequent 
transmission to MEM 10112 through DMOVR 20410, as will be described below. BMCAC 20418 transfers 
addresses received from ED 10124 to BMCATM 20432. BMCATTVI 20432 co"^fj"^^f?f^„™^ 
Information correlating ED 10124 addresses with MEM 10112 physical addresses. BMCATM 20432 ^er^y 
provides MEM 10112 physical addresses corresponding to ED 10124 addresses pro>dded through BMCAC 

^ When, as will be described further bdow, EBMC 20414 is granted access to MEM 10112 to write data 
into MEM 10112, data stored in BMCDB 20426 and corresponding addresses from BMCATM 20432 are 
transferred onto DMID Bus 20430 to DMOVR 20410. As will be described below, DMOVR 20410 then wrrtes 
that data into those MEM 101 12 physical address locations. When data Is to be read from MEM 101 12 to ED 
10124, data is provided by DMOVR 20410 on DMOD Bus 20428 and is transferred into BMCDB 20426, 
BMCAC 20418 then reads that data from BMCDB 20426 and transfers that data onto BMCAD Bus 20420 to 
ED 10124. During transfers of data from MEM 10112 to ED 10124, MEM 10112 do^ not provide addressee 
to be translated into ED 10124 addresses to accompany that data. Instead, those addresses are generated 
and provided by BMCAC 204ia ^ ^ 

NDC a>416 operates In a manner similar to that of EBMC 20414 except that data mputs and outputs of 
NDCAC 20422 are not buffered through a BMCDB 20426, 

As previously described, MEM 10112 has capacity to perform block transfers, tiiat is sequential 
transfers of four 32 Wt words at a time. In general, such transfers are performed through EBMC 20414 and 
are buffered thrtnigh BMCDB 20426. That is, BMCDB 20426 allows single 32 bit words to be recdved from 
ED 10124 by EBMC 20414and stored therein until a four word block has been received. That block may then 
be transferred to MEM 10112. Simllarty. a block may be received from MEM 10.112, stored in BMCPB 20426, 
and transferred one word at a time to ED 101 24. In contrast, NDC 20416 may generally be utilired for single 
word transfers. ,^ , 

As Indicated in Rg. 204, EBMC 20414, NDC 20416, and each data channel device of lOS 10116 each 
contain an indhndual address translation map, fbr example BMCATM 20432 In EBMC 20414 and NDCATM 
20436 in NDC 20416. Address translation maps stored therein are effedWely constructed and controlled by 
lOCP 20412 for each data channel device. lOS 10116 may thereby provide an indh^al and separate 
address translation map for each IDS 10116 data channel device. This allows IDS 10116 to Insure that no 
two data channel devices, nor two groups of data anks and sources in ED 10124, will mutually interfere by 
writing into ami destro>wig data in a common area of MEM 10112 physical address space. Atemately, lOS 
10116 may generate address translation maps for two or more data channel devices wherein those maps 
share a common, or overiapping, area of MEM 101 12*8 physical address space. This allows data stored in 
MEM 1011210 be transferred between lOS 10116 data channel devices through MEM 10112, and thus to be 
transferred between various data sink and source devices of ED 10124, For example, a first ED 10124 date 
source and afir^ lOS 10116 data channel may write data to be operated upon into a particular area cff MEM 
10112 address space. The results of CS 101 10 operations upon that data may then be written into a 
common area shared by tiiat first data device and a second data device and read out of MEM 10112 to a 
second ED 10124 data sink by tiiat second data channel device Indwldual mapping of lOS lOllB'a data 
channel devices thereby provides total flexibility in partitioning or sharing of MEM 101 IZs address space 
tiirough lOS lOlia 



2. I/O Control Processor 20412 

As described above, lOCP 20412 is a general purpose computer whose primary function is overall 
direction and control or data transfer t^tween MEM 10112 and ED 10124. lOCP 20412 controls mapping of 
addresses between ICS 10116's data channel devices and MEM 10112 address space. In this regard, lOCP 
20412 generates address translation maps for lOS 10116's data channel devices, such EBMC 20414 and 
NDC 20416. lOCP 204T2 loads these address translation maps into and controls, for example, BMCATM 
20432 of EBMC a)414 and NDCATM 20436 and NDC 20416 through lOCPC Bus 20434. lOCP 20412 also 
provides certain control functions to DMOVR 20410, as indicated tn Rg. 204. In addition to these functions, 
lOCP 20412 Is also provided with data and addressing Inputs and outputs. These data addressing Inputs 
and outputs may be utilized, for example, to obtain information utilized by lOCP 20412 in generating and 
controlling mapping of addresses between lOS 10116's data channel devices and MEM 10112. Also,tiiese 
data ami address inputs and outputs allow lOCP 20412 to operate, in part, as a data channel device. As 
previously described, lOCP 20412 has data and address inputs and outputs connected from and to DMID 
Bus 20430 and DMOD Bus 2042a lOCP 2041 2 thus has access to data being transferred between ED 1 0124 
and MEM 10112, providing I0CP20412 with direct access to MEM 10112 address space. In addition, lOCP 
20412 is provided witti control and address outputs to NDCAD Bus 20424, thus allowing lOCP 20412 partial 
control of certain data source and sink devices in ED 10124. 
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3. Data Mover 20410 <Rg. 269) 

a^. Input Data Buffer 20440 and Output Data Buffer 20442 
As described above, DMOVR 20410 comprises an interface between lOS 10116's data channels and 
WEWI 101 1 2. DMOVR 2041 0 performs actual transfer of data between lOS 101 1 B's data channel devices and 

s MEM 10112, and controls access between lOS 10116's data channel devices and MEM 10112. IDB 20440 
and ODB 20442 are <lata and address buffers allowing asynchronous transfer of data between lOS 10116 
and MEM 1 01 1Z That is, ODB 20442 may accept data from MEM 10112 as that data becomes available and 
then hold that data until an lOS 1 01 1 6 data channel device, for example EBMC 2041 4, is ready to accept that 
data. IDB 20440 accepts data and MEM 101 12 physical addresses from 105 101 16'$ data channel devices* 

to IDB 20440 holds that data and addresses for sufisiequent transmission to MEM 101 12 when MEM 101 1 2 is 
ready to accept data and addresses. IDB 20440 may, for example, accept a burst, or sequence, of data from 
EBMC 20414 or single data words from NDC 20416 and subsequently provide that data to MEM 10112 in 
blocEc or four word, transfers as previously described. Similarly, ODB 20442 may accept one or more block 
transfers or data from ODB 204^ and subsequently provide that data to NDC 20416 as single words, or to 

fs DMID 20430 as a data burst. In addition, as previous^ described, a block transfer from MEM 10112 may not 
appear as four sequential words. In such cases, ODB 20442 accepts the four words of a block transfer as 
they appear on MfO Bus 101 29 and assembles those words into a block comprising four sequential words 
for sut>sequent transfer to ED 1 01 24. 

Transfer of data through IDB 20440 and ODB 20442 is controlled by PRC 20444, which exchanges 

20 control signals with lOCP 20412 and has an interface, previously described, to MEM 10112 through lOMC 
Bus 10131. 



b.b. Priority Resolution and Control 20444 (Bg. 269) 

2S As previously described, PRC 20444 controls access tietween lOS 101 16 data chann^ devices and MEM 

10112. This operation is performed by n^eans of a Ring Grant Access Generator (RGAG) wthin PRC 20444. 

Referring to Rg. 270, a diagramic representation of PRC 20444's RGAG is shown. In general, PRC 
20444's RGAG is comprised of a Ring Grmit Code Generator <RGC6) 2®10 and one or more data channel 
request comparators. In fig. 269, PRC 20444's RGAG is shown as including ECLIPSE® Burst Muhiplexer 

so Channel Request Comparator (EBMCRC)26912, f^OVA® Data Channel Request Comparator (NDCRC) 26914, 
Data Channd Device X Request Comparator <DCDXRC) 26916, and Date Channel Device Z Request 
Comparator (DCDZRC) 26918. PRC 20444's RGAG may inchide more or fewer request comparators as 
required by the number of data channel devices within a particular lOS 10116. 

As indicated in Fig. 269, Request Grant Code (RGC) outputs of RGCG 26910 are connected In parallel to 

35 first inputs of EBMCRC 26912, NDCRC 26914, DCDXRC :^16, and DCDZRC 269ia Second inputs of 
EBMCRC 26912, NDCRC 26914, DODXRC 26916. and DCDZRC 26918 are connected from otfier portions of 
PRC 20444 and receive indications that respectwely, EBMC 20414, NDC 20416, DCDX, or DCDZ has 
submitted a request for a read or write access to MEM 10112. 

Request Gram Outputs (GRANT) of EBMCRC 26912, NDCRC 2®14, DCDXRC 26916, and DCDZRC 26918 

40 are in tu m connected to other port:ions of PRC 20444 circuitry to Indicate when read or write access to MEM 
10112 has been granted in response to a request by a particular lOS 10116 data channel device. When 
indication of such a grant is provided to those other portions of PRC 20444, PRC 20444 proceeds to generate 
appropriate control signals to MEM 10112, through lOMC Bus 10131 as previously described, to IDB 20440 
and ODB 20442, and to lOCP 20412. PRC 20444's control signals initiate that read or write request to that 

45 lOS 10116 data channel device. Grant outputs of EBMCRC 26912, NDCRC 26914, DCDXRC 26916, and 
DCDZRC 26918 are also provided as inputs to RGCG 26910 to indicate, as described further below, when a 
particular lOS 10116 has requested and been granted access to MEM 10112. 

As indicated in Fig. 269, a diagramic figure above RGCG 26910, RGCG generates a repeated sequence 
of unique RGCs. Herein indicated as numeric digits O to 15. Each RGC identifies, or defines, a particular 

50 time slot during which a lOS 10116 data channel device may be granted access to MEM 10112. Certain 
RGCs are, effecth^ely, assigned to particular lOS 10116 data channel devices. Each such data channel device 
may request access to MEM 10112 during Its assigned RGC identified access slots. For example, EBMC 
20414 is shown as being allowed access to MEM 10112 during those access slots identified by RGCs 0, 2, 4, 
6, B, 10. 12, and 14. NDC 20416 is indicated as being allowed access to MEM 101 12 during RGC slots 3, 7, 1 1, 

ss and 15. DCDX is allowed access during slots 1 and 9, and DCDZ is allowed access during RGC slots 5 and 

As described above, RGCG generates RGCs 0 to 15 in a repetitive sequence. Dunng occurrence of a 
particular RGC. each request comparator of PRC 20444's RGAG examines that RGC to determine whether 
its associated data channel device is allovred access during that RGC slot, and whether that associated data 
£0 channel device has requested access to MEM 10112. If that associated data channel device is allowed 
access during that RGC slot, and has requested access, that data channel device is granted access as 
indicated by that request comparator's GRANT output The request comparators GRANT output is also 
provided as an Input to RGCG 26910 to indicate to RGCG 26910 that access has been granted during that 
RGC slot 

If a particular data channel device has not claimed and has not been granted access to MEM 10112 
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during tiiat RGC dot R6CG 26910 will go directly to next RGC slot In next RGC slot, PRC 20444's RGAG 
again determines whether the particular data channel device aHowed access during that slot has submitted 
a request, and will gram access if such a request has been nnade. If not. RGC6 26910 will again proceed 
directly to next RGC slot, and so on. In this nianner, PRC 20444's RGAG insures that each data channel 

S device of lOS 10116 is allowed access to MEM 10112 without undue delay. In addition, PRC 20444's RGAG 
prevents a single, or more than one, data channel device from monopolizing access to MEM 10112. As 
described above, each data channel device is aHowed access tp MEM 101 12 at least once during a particular 
sequence of RGCs. At the same time, by not pausing vwthin a particular RGC in v\rtiich no request for access 
to MEM 10112 has occurred, PRC 20444's RGAG effectively automatically slops over those data channel 

fO devices which have not request«l access to MEM 1011 2. PRC 20444's RGAG thereby effectively provides, 
within 8 given time interval, more frequent access to those data channel devices which are most busy. In 
addition, the RGCs assigned to particular lOS 1011 B data channel devices may be reassigned as required to 
adapt a particular CS 10110 to the data Input and output requirements of a particular CS 10110 
configuration. That is, if EBMC 20414 is shown to require less access to MEM 10112 then NCX: 20416, 

w certain RGCs may be reassigned from EBMC 20414 to NDC 20416. Access to MEM 10112 by lOS 10116*s 
data channel devices may thereby be optimized as required. 

Having described structure and operation of lOS 10116, structure and operation of DP 10118 will be 
described next below. 



20 

E. Diagnostic Processor 10118 (Rgs. 101, 205) 

Referring to Rg. 101, as previously described, DP 101 18 is interronnected with lOS 101 16, MEM 101 1 2, 
FU 10120, and EU 10122 through DP Bus 10138, DP 101 18 Is also Interconnected, through DPIO Bus 10136, 
with the external worid and in particular with DU 10134. In addition to performing diagnostic and fault 

25 monKoring and oorredion operations, DP 101 18 operates, in part, to provide control and display functions 
allowing an curator to imerfece with CS lOlia DU 10134 may be comprised, for example, of a CfU and 
k^board unit, or a teletype, and provides operators of CS 10110 with all control and display functions 
which are convOTtionally provided by a hard console, that Is a console containing switches and lights. For 
example, DU 10134, through DP 10118, allows &n op^ator to exerdse control of CS 10110 tor such 

30 purposes as system Inttiaraation and startup, execution of diagnostic processes, fault monitoring and 
identification, and oontrol of execution of programs. As will be described further below, these functions are 
accomplishsd through DP 10118's interfaces with lOS 10116, MEM 10112, FU 10120, and EU 10122. 

DP 10118 is a general purpose computer system, for example a NOVA* 4 computer of Data General 
Corporation of Westboto, Massachusetts. Interface of OP 10118 and DU 10134, and mutual operation of DP 

35 10118 and DU 10134, will be readily apparent to one of ordinary skill In the art. DP 10118's interface and 
operation, vdtfi lOS 10116^ MEM 10112, FU 10120, and EU 10122 will be described further next below. 

DP 101 18, operating as a general purpose computer programmed spedficiaUy to perform the functions 
described above, has, as will be described below, read and write access to registers of IDS 101 16, MEM 
10112, FU 10120 and EU 10122 thmgh DP Bus 10138, DP 10118 may read date directlyfrom and write data 

40 directiy into those registers. As will be described below, these registers are date and instruction registers 
and are integral parts of CS 101 10's drcuitry during normal operation of CS 10110. Access to these registers 
tiiereby allows DP 1 01 18 to directly control or effect operation of CS 101 10. In addition, and as also will be 
described below, DP 10118 provides. In general, all dock signals to all portions of CS 10110 circuitry and 
may control operation of that circuitry through oontrol of these clock signals. 

45 For purposes of DP 10118 functions, CS 10110 may be regarded as subdhridol into groups of 
functionally related elements, for example DESP 20210 In FU 10120. DP 10118 obtains access to tiie 
registers of these groups, and control of ck>cks therein, through scan chain drcuite, as will be ctescribed 
next betow. In general, DP 101 18 is provided with one or more scan chain drcutts for each major functional 
sub-element of CS 10110. 

so Referring to fig. 205, a diagramic representetion of DP 10118 and a typical DP 10118 scan chain is 
shown. As indicated therein, DP 10118 indudes a general purpose Central Processor Unit, or computer, 
(DPCPU) 27010. A first interface of DPCPU 27010 is with DU 10134 through DPIO Bus 10136. DPCPU 27010 
and DU 10134 exchange date and control signals through DPIO Bus 10136 in the manner to direct 
operations of DPCPU 27010, and to display the results of those operations through DU 10134. 

ss Assodated with DPCPU 27010 is Clock Generator <CLKG) 27012. CLKG 27012 generates, in general, all 
dock signals used within CS 101 10. 

DPCPU 27010 and CLKG 27012 are interfaced with the various scan chain circuits of CS 1011 0 through 
DP Bus 10138. As described above, CS 10110 may indude one or more scan chains for each major sub- 
element of CS 10110. One such scan chain, for example DESP 20210 Scan Chain (DESPSC) 27014 is 

&) illustrated In Rg. 205. ^ ^ 

Interface between DPCPU 27010 and CLKG 27012 and, for example, DESPSC 2701 4 is provided through 
DP Bus 10138. As indicated in Rg. 205, DESPSC 27014 indudes Scan Chain Dock Gates (SCCG) 27016 and 

one or more Scan Chain Registers (SCRs) 27018 to 27024. 

SCCG 27016 receh^es dock signals from CLKG 27012 and control signals from DPCPU 27010 through 

es DP Bus 10138. SCCG 27016 in tum provides apprt^ate dodt signals to the various regtsteis and drcuits 
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of, for example, DESP 20210. Clock control signals provided by DPCPU 27010 to SCCG 27016 corjtrol. or 
gate, the various dock signals to these registers and circuits of DESP 20210, thereby effectively allowing 
DPCPU 27010 to control of DESP 20210. 

SCBs 27018 to 27024 are comprised of various registers wHhin DESP 20210. For example, SCRs 2701B 

S to 27024 may Include the output buffer registers of AONGRF 20232, OFFGRF 20234, LENGRF 202^. o^ut 
registers of OFFALU 20242 arid LENALU 20252, and registers within OFFMUX 20240 and BIAS 20246. Such 
registers are indicated in the present description, as previously described, by arrows appended to ends of 
those registers, vinth a first arrow Indicating an input and a second an output. In nomial CS 10110 
operations, as previously described, SCRs 27018 to 27024 operate as parallel in, parallel out buffer registers 

to through which data and Instructions are transferred. SCRs 27018 to 27024 are also capable of operating as 
shift registers and, as indicated in Rg, 205, are connected together to comprise a single shift register circuit 
having an Input from DPCPU 27010 and an output to DPCPU 27010. Control inputs to SCRs 27018 to 27024 
from DPCPU 27010 control operation of SCRs 27018 to 27024, that is whether these registers shall operate 
as parallel In, parallel out registers, or as shift registers of DESPSC 270U's scan chain. The shift register 

IS ' scan chain comprising SCRs 27018 to 27024 allows DPCPU 27010 to read the contents of SCRs 27018 to 
27024 by shifting ^e content of these registers into DPCPU 27010. Conversely, DPCPU 2701 0 may wnte into 
SCRs 27018 to 27024 by shifting Information generated by DPCPU 27010 from DPCPU 27010 and through 
the shift register scan chain to selected locations within SCRs 27018 to 27024. 

Scan chain dock generator drcuits and scan chain registers of each scan chain drcuit vwthin CS 101 10 

20 thereby allow DP 101 18 to control operation of each major sub-element of CS 101 1 0. For example, to read 
infbmiation from the scan chain registers therein, and to write infonnation into those scan chain registers 
as required for diagnostic, monitoring, and control functions. c.^.-^^ 

Having described structure and operation of each major element of CS 10110, including MEM 101 12, 
FU 10120, EU 10122, lOS 10116, and DP 10118, certain operations of. In particular, FU 10120 will be 

2S descnbed further next below. The following descriptions will forther disclose operational features of JP 
10114, and in paitioular FU 10120, by describing in greater detail certain operations thermn by further 
describing microcode control of JP 101 14. 

3Q F. CS 10110 Wficromachlne Structure and Operation (Rgs. 270--274) 

a. Introduction , ^. ^cih/%^oa ^nn 

The preceding descriptions have presented the hardware structures and operation erf FU 101 20 and EU 
10122. -me follovXna description will describe how devices in FU 10120, and certain EU 10122 devic^ 
function together as a microprogrammable computer, henceforth temwd the FU micromachlne. The FU 

55 micromadiine performs two tasks: It Interprets SINs, and it responds to certain sigmjis generated by 
devices in FU 10120. EU 10122, MEM 10112. and tOS 10116. The signals to which the FU mscromachine 
responds are termed Event signals. In terms of structure and operation, the FU micromac^ine is 
characterized by the following: 

Registers and ALUs ^Mcialized for the handling of logical descriptors. - 

40 — Registers organized as stacks for invocations of microroutlnes (microinstruction sequences). 

— Mechanisms aHowingmicroroutine Invocations by ineans of event signals from hart^^ 

— Mechanisms which allow an invoked microroutineto return either to the microinstruction following the 
one which resulted in the invocation or to the microinstruction whidi resulted in tfje ^^J^^^- 

— Mechanisms which allow the contents of stack registers to be transferred to MEM 10112, ttiereoy 
4ff creating a virtual microstack of limitless size. ^ * 

Mechanisms which guarantee response to an event signal within a predictable length ot time. 
^ The division of the devices comprising the micromachine into two groups: those devices wrtiidi may be 

used by all microcode and those which may be used only by KOS {Kernel Operating System, 

previously described) microcode. , , ■ 

so These devices and mechanisms allow the FU micromachine to be used in two ways: as a vtrtua 
micromachine and as a monitor micromachine. Both kinds of micromachine use the same devices in FU 
10120, but perform different functions and have different logical properties. In the following discussion, 
when the FU micromachine is being used as a virtual micromachine, it is said to be in virtual mode, and 
when It is being used as a monitor micromachine, it is said to be in monitor mode. Both modes are 
SB introduced here and explained in detaillater. ._ ^ • 

When the FU micromachine is being used in virtual mode, it has the following properties. 

— It runs on an essentially Infinite micromachine stack belonging to a Process 610. 

— It can respond to any number of event signals in the MO cycle (state) of a single microinstruction. 

— A page fault may occur on the invocation of any microroutine or on retum from any microroutine. 
la, When the FU micromachine is in virtual mode, any microroutine may not run to completion, i.e., 

complete its execution in a predictable length of time, or complete it at all. 

— It is executing a Process 610. . , . . ^, 

The last four properties are consequences of the first: Event signals result in invocations, and since the 
micromachine stack is infinite, there is no limit to the number of invowtions. The 
sLck 18 realized by placing micromachine stack frames on Secure Stack 10336 belonging to a l^rocess 610, 
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and the virtual micromachine therefore always runs on a micronnachine stack belonging to some Pro<^s 
610. Furthermore, if the invocation of a microroutine or a return from a microroutine requires 
micromachine frames to be transferred from Secure Stack 10336 to the FU micromachine, a page fault may 
result and Process 610 whidi is executing the microroutine may be removed from JP 10114, thereby 

^ making the time required to execute the microroutine unpredictable. Indeed, if process 610 is stopped or 
Idlled, the execution of the microroutine may never finish. As v^ill be seen in descriptions below, the Virtual 
Processor 612 is the means by which the virtual micromachine gains access to a Process 610's 
micromachine stack. 

When in monitor mode, the FU micromachine has the following properties: 

10 It has 8 micronnachine stack of fixed size, the stack is always available to the FU micromachine, and H is 
not associated with a Process 610. 

— It can respond to only a fixed number of events cjuring the MO cyde of a single microinstruction. 

— In monitor mode, invocation of a microroutine or return from a microroutine will not cause a page 
fault • 

15 — Mtcroroutines executing on the FU micromachine when the micromachine is in monitor mode are 
guaranteed to run to completion unless they themselves perform an action which causes them to give 
up JP 10114. 

— Microroutines executing in monitor mode need not be performing functions for a Process 610. 
Again, the remaining properties are consequences of the first: because the monitor micromachine's 

stack is oif fixed aze, the number of events to which the monitor micromachine can respond is limited; 
furthermore, since the stack is always directly accessible to the micromachine, microroutine invocations 
and returns will not cause page fauH^ and microroutines running in monitor mode will run to completion 
unless they themselves perform an action which causes them to ghre up JP 10114. Finally, the monitor 
micromachine's stack is not associated with a Process 610's Secure Stack 10336, and therefore, the monitor 

^ micromachine can both execute functions for Processes 610 and execute funcUons (which arB related to no 
Process 610, for example,) the bincfing and removal of Virtual Processors 612 from JP 101 14. 

The description which follows first gives an overview of the devices which make up the micromachine, 
continues v«th descnptions of invocations on the micromachine and micromachine programming, and 
concludes vwth detailed discussions of the virtual and monitor modes and an overview of the relationship 

30 between the micromachine and CS 10110 subsystems. The manner in which the micromachine performs 
specific operations such as SIN parsing. Name resolution, or addtess translation may be found in previous 
descnptions of CS 10110 components which the micromachine tises to perform the operatiors. 

35 b. Overview of D6>nce Comprising FU Micromachine (Fig. 270) 

Rg. 270 presents an overview of the devices comprising the micromachine. Fig. 270 is based on Rg. 
201, but has been amplified to Improve the clarity of the discussion. Devices and subdivisions of the 
micromachine which appear in Rg. 201 have the numbers given them In that figure. When a device in Rg. 
270 appears in two subdWisions, it is shared by those subdivisions. 
40 Rg. 270 has four main subdivisions. Three of them are from Rg. 201 : FUCTL 20214, which contains the 
devices used to select the next microinstruction to be executed by the micromachine, DESP 20210, which 
contains stack and global registers and ALUs for descriptor proofing; and MEMIhfT 20212, which 
contains the devices which translate Names into logical descriptors and logical descriptors into physical 
descriptors. The fourth subdivision, EU Interface 27007. represents those portions of EU 10122 which may 
45 be manipulated by FU 10120 microcode. 

Rg. 270 further subdivides FUCTL 20214 and MEMIMT 20212. FUCTL 20214 has four Gufodivi^ons: 
NStream Reader 27001, which contains the devices used to obtain SINs and parse them into SOPs and 
Names. 

— SOP Decoder 27003, which translates SOPs into locations in FU microcode (FUSTTT 11012), and in 
SO some cases EU microcode (EUSITT 20344), which contain the microcode that performs the 

corresponding SINs. 

— Microcode Addr^sing 27013, which determines the location of the next microinstruction to be 
executed in FUSITT nOIZ 

— Register Addressing 2701 1 , which contains devices which generate addresses for GRF 10354 registers. 

MEMINT 20212 also has three subdivisions: 

— Name Translation Unit 27015, which contains de^^ces which accelerate the translation of Names Into 
logical descriptors. 

— Memory Reference Unit 27017, which contains devices which accelerate the translation of logical 
€0 descriptors into physical descriptors. 

— Protection Unit 27019, which contains devices which accelerate primitive access checks on memory 
references made with logical descriptors. 

Rg, 270 also simplifies tfte bus structure of Rg. 202 by combining LENGTH Bus 20226, OFFSET Bus 
20228« and AONR Bus 20230 into a single structure. Descriptor Bus (DB) 27021. In addition, intemal bus 
CS connections have been reduced to those necessary for explaining the logical operation of the 
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micromachine. The following discussion first describes those devices used by most microcode executing 
on FU 10120, and then describes devices used to perform special functions, such as Name translation or 
protection checking. 



to 



1. Devices used by Most Microcode . j nn- ^ 

The subdivisions of the micromachine vvhich contain devices used by most microcode are Microcode 
Addressing 27013, Register Addressing 27011, DESP 20210, and EU Interface 27007. In addition, most 
microcode uses MOD Bus 1 0144, JPD Bus 10142, and DB Bus 27021. The discussion begins with the buses 
and then describes the other devices in the above order. 



a.a, MOD Bus 10144, JPD Bus 10142, and DB Bus 27021 
MOD Bus 10144 Is the only path by which data may be obtained from MEM 10112. Data on MOD Bus 
IS 10144 may have as Its destination Instruction Stream Reader 27001, DESP 20210, or EU Interface 27007. In 
the firet case, the data on MOD Bus 10144 consists of SINs; in the second, it is data to be processed by FU 
10120, and in the third, it is date to be processed by EiJ 10122. In the present embodiment, data to be 
processed by RJ 10120 is generally data whlch .is destined for internal use in FU 10120, for example in 
Name Cache 10226, Data to be processed by £U 10122 is generally operands represented by Names in 
20 SINs. 

JPD Bus 10142 has two uses: it is the path by which data returns to MEM 10112 after it has been 
processed by JP 10114, and It Is the path by which data other than logical descriptors moves between the 
subdh^lons of the micromachine. For example, when CS 10110 Is Initialized, the micrcinstrucdons which 
are loaded into FUSITT 11012 are transferred from MEM 10112 to DESP 20210 via MOD Bus 10144, and 
25 from DESP 20210 to FUSITT 11012 via JPD Bus 10142. 

DB 27021 is the path by which logical descriptors are transferred in the micromachina DB 27021 
. connects Name Translation Unit 27015, DESP 20210, Protection Unit Z7019, and Memory Reference Unit 
' 27017. Typically, a logical descriptor is obtained from Name Translation UnH 27015, placed in a register in 
DESP 20210. and then presented to Protection Unit 27019 and Memory Reference Unit 27017 whenever a 
30 reference is made using a logical descriptor. However, DB 27021 is also used to transmit cache entries 
fabricated in DESP 20210 to ATU 1022B, Name Cache 10226 and Protection Cache 10234. 



b.b. Microcode Addressing 

35 As discussed here, microcode addressing is comprised of the following devices: Time rs 20296, Event 
Ugic 20284, ROWS 10358, BRCASE 20278, mPC 20276, MCWO 20292, MCW1 20290, SITTNAS 20286, and 
FUSITT 1 1012. All of these devices have already been de»:rlbed In detail, and they are discussed here only 
as they affect microcode addressing. Other devices contained in Rg. 202, State Registers 20294, Repeat 
Counter 20280, and PNREG 20282 are not directly relevant to microcode addressing, and are not discussed 

40 here. 

As has already been described In detail, devices In Microcode Addressing 27013 are loaded from JPD 
Bus 10142. The microcode addresses provided by these devices and by FUSDT 11010 are transmitted 
among the devices and to FUSITT 11012 by CSADR Bus 20204. There are ax ways in which the next 
microcode address may be obtained: 
45 — Most commonly, the value in mPC 20276 is incremented, by 1 by a special ALU in mPC 20276, thus 

yielding the address of the microinstruction following the current microinstruction. 

— If a microinstruction specifies a call to a microroutine or a branch, the microinstruction contains a literal 
which an ALU in BRCASE 20278 adds to the value in mPC 20276 to obtain the location of the next 
microinstruction. 

fio — If a microinstruction specifies the use of a case value to calculate the location of the next 
microinstruction, BRCASE 20278 adds a value calculated by DESP 20210 to the value in mPC 20716. 
The value calculated by DESP 20210 may be obtained from a field of a logical descriptor, thus allowing 
the micromachine to branch to different locations in microcode on the basis of type information 
contained in the logical descriptor. On return from an Invocation of a microroutine, the location at 

55 which execnjtion of the microroutine in which the invocation occurred is to continue is otytained from 
RCWS 10358. 

— At the beginning of the execution of an SIN, the location at which the microcode for the SIN begins is 
obtained from the SIN's SOP by means of FUSDT 11010. 

— Certain hardware signals cause invocations of microroutines. There are two classes of such signals: 
eo Event signals, which Event Logic 20284 transforms into invocations of certain microroutines, and JAM 

signals, which are translated directly into locations in microcode. 

The addresses obtained as described above are transmitted to SITTNAS 20286, vi/hich selects one of 
the addresses as the location of the next microinstruction to be executed and transmits the location to 
FUSrmi012. As the location is transmitted to FUSITT 11012, It is also stored in mPC 20276. All addresses 
es except those for Jams are tranferred to SITTNAS 20286 via CSADR Bus 20204. Addresses obtained from 
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JAM signals are transferred by sepatate lines to SHTNAS 20286. 

As will be explained in detail below, microroutine calls and returns also involve pushing and popping 
micromachine stack frames and saving state contained in MCWl 20290. 

Register Addressing 27011 controls access to micromachine registers contained in GRF 10354. As 
^ explained in detail below, GRF 10354 contains both registers used for the micromachine stack and global 
registers, that is, registers that are ahvays accessible to ali microroutines. The registers are grouped in 
frames, and tndhddual registers are addressed by frame number and register number. Register Addressing 
2701 1 allows addressing of any frame and register in the GRs 10360 of GRF 10354, but allows addressing of 
registers in only three frames of the SR's 10362: the current (top) frame, the previous frame {ue^ the frame 
preceding the top frame), and the bottom frame, that is, the lowest frame in a virtual micromachine stack 
which Is still contained In GRF 10354. The values provided by Register Addressing 27011 are stored In 
MCWO 20292. As will be explained in the discussion of microroutine invocations which follows, current and 
previous are incremerned on each invocation and decremented on each return. 

75 

cc Description Processor 20210 (Rg. 271) 
DESP 20210 is a set of devices for storing and processing logical descriptors. The internal structure of 
DESP 20210's processing devices has already been explained in detail; here, the discussion deals primarily 
with the structure and contents of GRF 10354. In a present embodiment of CS 101 10, GRF 10354 contains 
20 256 registers. Each register may contain a single logical descriptor. Ftg. 271 Illustrates a Logical Descriptor 
27116 in detail. In a present embodiment of CS 101 10, a Logical Descriptor 27116 has four main fields: 

— RS Reld 27101, which contains various flags which are explained In detail below. 

— AON field 271 11, which contains the AON portion of the address of the data item represented by the 
Logical Descriptor 27116. 

2S — OFF Field 27113, which contains the offset portion of the address of the data Item represented by 
Logical Descriptor 27116. 

— LEN Field 27115, which contains the length of the data item represented by the Logical Descriptor 
' 27116. 

RS Field 27101 has subfields as follows: 
30 — RTD Field 27103 and WTD Field 271C» may be set by microcode to disable certain Event signals 
provided for debuggers by CS 10110. For details, see a following description of debugging aids in CS 
lOlia 

— RU Reld 271 07 contains two bits. The fields are set from information In the Name Table Entry used to 
construct the Logical Descriptor 2711& The bits determine how the data specified by the Logical 

as Descriptor 27116 Is to be ju^fted and filled when it is fetched from MEM 101 12. 

— TYPE Reld 271<^s four bits are also obtained from the Name Table Entry used to coitstnict the Logical 
Descriptor 271 ia The field's settings vary from S-Language to S-Language, and are used to 
communicate S-Language-specifIc type Information to the S-Language's S-lnterpreter microcode. 
The four fields of a Logical Descriptor 271 16 are contained in three separately-accessible fields in a GRF 

40 10354 register: one containing RS Reld 27101 and AON Field 27111, one containing OFF Reld 27113, and 
one containing LEN Reld 27115. In addition, each GRF 10354 register may be accessed as a whole. GRF 
10354 is further subdivided into 32 frames of eight registers each. An individual GRF 10354 register is 
addressed by means of its frame number and Its register number within the frame. In a present 
embodiment of CS 10110, half of the frames in GRF 10354 belong to SR's 10362 and are used for 

4S micromachine stacks, and half belong to GRs 10360 for storing "global Information". In SR's 10362, each 
GRF 10354 frame contains information belonging to a single invocation of a microroutine. As previously 
explained. Register Addressing 2701 1 allows addressing of only three GRF 10354 frames in SR's tack 1 0362, 
the current top frame in the stack, the previous frame, and the bottom frame. Registers are accessed by 
specifying one of these three frames and a register number. 

so The global information contained in GRs 10360, Is Information which is not connected with a single 
invocation. There are three broad categories of global information: 

— Information belonging to Process 610 whose Virtual Processor 612 is currentiy bound to JP 10114. 
Included in this information are the current values of Process 610*8 ABf^ and the pointers which KOS 
uses to manage Process 610's stacks. 

ss — Information required for the operation of KOS. Included In this information are such items as pointers 
to KOS data bases which occupy fixed locations In MEM 101 1Z 

— Constants, that is, fixed values required for certain frequentiy performed operations in FU 10120. 
Remaining registers are available to microprogrammers as temporary storage areas for data which 

cannot be stored in a microroutine's stack frame. For example, data which is shared by several 
60 microroutines may best be placed in a GR 10360. Addressing of registers in the GRs 10360 of GRF 10354 
requires two values: a value of 0 through 15 to specify the frame and a value of 0 through 7 to specify the 
register in the frame. 

As previously discussed in detail, each of the three components AONP 20216, OFFP 20218, and LENP 
20220 of DESP 20210 also contains ALUs, registers, and logic which allows operations to be performed on 
^ indhfidual fields of GRF 10354 registers. In particular, OFFP 20218 contains OFFALU 20242, which may be 
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used as a general purpose 32 bit arithmetic and logical unit. OFFALU 20242 may further serve as a source 
and destination for JPD Bus 10142, the offset portion of DB 27021, and NAME Bus 20224, and as a 
destination for MOD Bus 10144. Consequently, OFFALU 20242 may be used to perform operations on data 
on these buses and to transfer data from one bus to another. For example, when an SIN contains a literal 
s value used in address calculation, the literal value is transferred via NAME Bus 20224 to OFFALU 20242, 
operated oHr and output via the offset portion of DB 27021. 

d.d. EU 10122 Interface 

FU 10120 specifies wrtiat operation EU 10122 is to pcrformr what operands it is to perform It on, and 
when It is finished, what is to be done with the operands. FU 10120 can use two devices in EU 10122 as 
deistlnations for data, and one device as a source for data. The destinations are COMQ 20342 and OPB 
20322. COMQ 20342 receives the location in EUSITT 20344 of the microcode which is to perform the 
operation desired by the FU 10120. COMQ 20342 may receive the location In microcode either from an FU 
10120 microroutlne or from an SIN's SOP. In the first case, the location is transferred via JPD Bus 10142. 
and in the second, it rs obtained from EUSDT 20266 and transferred via EUDIS Bus 20206. OPB 20322 
receives the operands upon which the operation is to be performed. If the operands come directly from 
MEM 10112, they are transferred to OPB 20322 via MOD Bus 10144; if they come from registers or devices 
in FU 10120, they are transferred via JPD Bus 10142. 

Result Register 27013 is a source for data. After EU 10122 has completed an operation, FU 10120 
^ obtains the result from Result Register 27013. FU 10120 may then place the result in MEM 10112 or in any 
device accessible from JPD Bus 10142. 

2. Specialized Micromachine Devices 

Each of the groups of specialized devices serves one of OS 10110's subsystenns. I-Stream Reader 27001 
^ is part of the S<lnterpreter subsystem^ Name Translation Unit 27015 is part of the Name Interpreter 
subsystem. Memory Reference Unit 27017 is part of the Virtual Memory Management System, and 
Protection Unit 27019 is part of the Access Control System. Here, these devices are explained only In the 
context of the mtcromachtne; for a complete understanding of their functions within the subsystenns to 
which they belong, see previous descriptions of the subsystems. 

30 

cua. I-Str«m Reader 27001 
l-Stream Reader 27001 reads and parses a stream of SlNs (termed the l-Stream) from a Procedure 
Object e04, 606, 608. The l-Stream consists of SOPs (operation codes), Names, and literals. As previously 
memioned, in a present embodiment of CS 101 10, the l-Stream read from a given Procedure 602 has a fixed 
35 format: the SOPs are 8 bits long and the Names and literals all have a single length. Depending on the 
procedure, the length may be 8, 12, or 16 bits, l-Stream Reader 27001 parses the l-Stream by breaking it up 
into its constituent SOPs and Names and passing the SOPs and Names to appropriate parts of the 
micromachine. l-Stream Reader 27001 contains two groups of devices: 

— ' PC Values 27006, which is made up of three registers which contain locations in the l-Stream, When 
40 added to ABP PBP, the values contained in these registers specify locations in Procedure Object 901 

containing the Procedure 602 being executed. CPC 20270 contains the location of the SOP or Name 
currently b^'ng Interpreted; IPC 20272 contains the location of the beginning of the SIN currently being 
executed; EPC 20274, finally, is of interest only at the beginning of the execution of an SIN; at that time, 
it contains the location of the last SIN to be executed. 
4S — Parsing Unit 27005, which is made up of INSTB 20262, PARSER 20264, and PREF 20260. The 
micromachine uses PREF 20260 to create Logical Descriptors 27116 for the l-Stream, which are then 
placed on DB Bus 27021 and used in logical memory references. The data retumed from these 
references is placed in INSTB 20262, and parsed by PARSER 20264. 

SOPs, Names, and literals obtained by PARSER 20264 are placed on NAME Bus 20224, which connects 
so PARSER 20264, SOP Decoder 27003, Name Translation Unit 27015. and OFFALU 2024^ 

b.b. SOP Decoder 27003 
SOP Decoder 27003 decodes SOPs into locations in FU 10120 and EU 10122 microcode, SOP Decoder 
27003 comprises FUSDT 11010, EUSDT 20266, Dialect Register (ROIAL) 24212, and LOPOCODE 24210. 
» FUSDT 1 1010 are further comprised of FUDISP 24218 and FALG 24220. The manner In which these devices 
translate SOPs contained in SINs Into locations in FUSITT 11012 and EUSITT 20344 has been previously 
described. 

cc. Name Translation Unit 27015 
eo Name Translation Unit 27015 accelerates the translation of Names into Logical Descriptors 271 16. This 

operation is termed name resolution. It is comprised of two components: NC 1 0226 and Name Trap 20254. 

NC 10226 contains copies of information from a Procedure Object 604's Name Table 10350, and thereby 

mates it possible to translate Names into Logtcal Descriptors 271 16 without referring to Name Table 10350. 

When a Name is presented to Name Translation Unit 27015. it is latched into Name Trap 20254 for later use 
6S by Name Translation Unit 2701 5 if required. As will be explained in detail later, in the present embodiment. 



123 



EP 0 087 556 B1 



Name translation always begins with the presentation of a Name to NC 10226. If the Hame has already 
been translated, the Information required to construct its Logical Descriptor 271 16 may be contained in NC 
10226. If there is no information for the Name in NC 10226, Name Resolution Microcode obtains the Name 
from Name Trap 20254, uses information from Name Table 10350 for the procedure being executed to 
s translate the Name, places the required information in NC 10226, and attempts the translation again. When 
the translation sucoeecte, a Logical Descriptor 27116 corresponding to the Name is produced from the 
information in Name Cache 10115, placed on DB Bus 27021, and loaded into a GRF 10354 register. 



w d.d, Menrary Reference Unit 27017 

Memory Reference Unit 27017 performs memory references using Logical Descriptors 27116. Memory 
Referertce Unit 27017 receives a command for MEM 10112 and a Logical Descriptor 27116 describing the 
data upon which the command is to be performed. In the case of a write operation. Memory Reference Unit 
27017 atso recehres the data being written via JPD Bus 10142. Memory Reference Unit 27017 translates 

75 Logical Descriptor 271 1 6 to a physical descriptor and transfers the physical descriptor and the command to 
MEM 10112 via PD Bus 1014& A Memory Reference Unit 27017 has four components: ATU 10228, which 
contains copies of information from KOS virtual memory management system tables, and thereby 
accelerates togical-to-physical descnptor translation; Descriptor Trap 20256, which traps Logical 
Descriptors 27116, Command Trap 27018, which traps memory commands; and Data Trap 20258^ which 

20 traps data on write operations. When a logical memory reference is made, a Logical Descriptor 27116 is 
presented via DB Bus 27021 to ATU 10228, and at the same time. Logical Descriptor 271 16 and the memory 
command are trapped in Descnptor Trap 20256 and Command Trap 27018. On write operations, the data to 
be written is trapped in Data Trap 20258. If the information needed to form the physical descriptor is 
present in ATU 10228, the physical descriptor fe transferred to MEM 10112 via PD Bus 10146. If the 

25 information needed to form the physical descriptor is not present in ATU 10228, an Event Signal from ATU 
10228 Invokes a microroutine which retrieves Logical Descriptor 27116 from Descriptor Trap 20256 and 
uses information contained in KOS virtual memory managemerrt system tables to make an entry in ATU 
10228 for Logical Descriptor 27116. When the microroutine returns, the logical memory reference is 
repeated using Logical Descriptor 27116 from Descriptor Trap 20256, the memory command from 

30 Command Trap 2701 8, and on write operations, the data in Data Trap 2025& As v^ll be described in detail in 
the discussion of virtual memory management if the data referenced tiy a logical memory reference is not 
present in MEM 10112, the logical memory reference causes a page fault. 



3B e,e. The Protection Unit 27019 

On each logical memory reference. Protection Unit 27019 checks whether the subject making the 
reference has access rights which allow it to perform the action specified by the memory command on the 
object being referenoed If the subject does not have the required access rights, a signal from Protection 
Unit 27019 causes MEM 10112 to abort the logical memory reference. Protection Unit 27019 consists of 

40 Protection Cache 1 0234, which contains copies of information from KOS Access Control System tables, and 
thereby speeds up protection checking, and shares Descriptor Trap 20256, Command Trap 27018, and Data 
Trap 20258 with Memory Reference Unit 27017. When a logical memory reference is made, the AON and 
offset portions of the logical descriptor are presented to Protection Cache 10234. If Prote<^on Cache 10234 
contains protection information for the object specified by the AON and offset and the subject performing 

9S the memory reference has the required access, the memory reference may continue; if Protection Cache 
10234 contains protection information and the subject does not have the required access, a signal from 
Protection Cache 10234 aborts the memory reference. If Protection Cache 10234 does not oont^n the 
required access information, a signal from Protection Cache 10234 at>orts the memory reference and 
invokes a microroutine v/htch obtains the access information from KOS Access Control System tables and 

50 places it in Protection Cache 10234. When Protection Cache 10234 is ready, the memory access is repeated, 
using the logical descriptor from Descriptor Trap 20256, the memory command from Command Trap 
2701 8« and in the case of write operations^ the data in Data Trap 20258. 



ss f*f» KOS Micromachine Devices 

As mentioned in the above introduction to the micromachine, the devices making up the 
micromachine may be divided imo two classes: those which any microcode written for the micromachine 
may manipulate, and those which may be manipulated exclusively by KOS microcode. The latter class 
consists of certain registers In GRs 10360 of GRF 10354, the bottom frame of the portion of the virtual 

so micromachine stack in the stack portion (Stack Aegtsters 10362) of GRF 10354, and the devices contained in 
Protection Unit 27019 and Memory Reference Unit 27017. Because Prcytection Unit 27019 and Memory 
Reference Unit 27017 may be manipulated only by KOS microcode, non-KOS microcode may not use 
Descriptor Trap 20256 or Command Trap 27018 as a source or destination, may not load or invalidate 
registers in ATU 10228 or Protection Cache 10234, and may not perfonm physical memory references, i.e., 

eg memory references ^ich place physical descriptors di rectiy on PD Bus 1 0146, instead of presenting logical 
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descriptore to Memory Reference Unit 27017 and Protection Unit 27019. Similarly, non-KOS microcode 
may not specify KOS registers in the GRs 10360 of GRF 10^ or the bottom frame of the stack portion of 
GRF 10354 when addressing GRF 10354 registers. Further, in embodiments allowing dynamic loading of 
FUSITT 11012, only KOS microcode may manipulate the devices provided for dynamic loading. 

5 In a present embodiment of CS 101 1 0. the distinction between KOS devices and registers and devices 

and registers accessible to all microprograms is maintained by the microbinder. The microbinder checks all 
microcode for micro! nstmctions vy^ich manipulate devices in Protection Unit 27019, or fViemory Reference 
Unit 27017, or which address GRF 10354 registers reserved for KOS use. However, it is characteristic of the 
micfomachine that KOS devices are logically and physically separate from devices accessible to all 

10 microprograms and, consequently, other embodiments of CS 10110 may use hardware devices to prevent 
non-KOS microprograms from manipulating KOS devices. 

c. Micromachine Stacks and MicroroutinB Calls and Returns (Figs. 272, 273) 

IS 1. Micromachine Stacks (Fig. 272} 

As previously mentioned, the FU micromac^ine is a stack micromachine The properties of the FU 
micromachlne's stack depends on whether the FU micromachine is in virtual or monitor mode. In virtual 
mode, the micromachine stack is of essentially unlimited size; if it contains more frames than allowed for 
inside FU 10120, the top frames are in GRF 10354 and the remaining frames are in Secure Stack 10336 

20 belonging to Process 610 being executed by the FU micromachine. In the following, the virtual mode 
micromachine stack is termed the virtual micromachine stack. In monitor mode, the micromai^ine stack 
consists of a fixed amount of storage; in a present embodiment of CS 10110, the monitor mode 
micromachine stack Is completely contained in the stack portion, SRs 10362, of GRF 10354; in other 
embodiments of CS 101 10, part or all off the monitor mode micromachine stack may t>e contained in an area 

25 of MEM 10112 which has a fixed size and a fixed location known to the monitor micromachine. In yet other 
embodiments of CS 10110, monitor mode micronwchine stack may l)e of flexible depth in a manner similar 
to the virtual micromachine stack. In either mode, microroutines other than certain KOS microroutines 
which execute state save and restore operations may access only two frames of GRF 10354 stack: the frame 
upon which the microroutlne is executing, called the current frame, and the frame upon which the 

30 mtcroroutinethat invoked that microroutlne exectited, called the previous frame. KOS microroutines which 
execute state save and restore operations may in addition access the ft>ottom frame of that portion of the 
virtue micromachine stack which is contained in GRF 10354. 

Rq. 272 illustrates stacks for the FU micromachine. Those portions of the micromachine stack whtdi 
are contained in the FU are contained in SB's 10362 (off GRF 10354) and in RCWS 10358. Each register of 

3S RCWS 10358 Is permanently associated with a GRF frame in SRs 10362 of GRF 10354, and the RCV\^ 10358 
register and the GRF frame together may contain one frame of a micromachine stack. As previously 
describe, each register of GRF 10354 comalns three fields: one for an AON and other information, one for 
an offset, and one for a length. As fllusirated In Rg. 251, each register in RCWS 10358 contains four fields: 

— A one bit field which retains the value off the Condition Code register in MCW1 20290 at the time that 
4Q the invocation which created the next frame occurred. 

— A field indicating what Event Signals were landing at the time that the invocation to which the RCWS 
register belongs invoked another microroutine. 

*— A flag indicating whether the microinstruction being executed when the invocation occurred was the 
first microinstruction In an SIN. 

4g — The address at which the execution of the invoking microroutine is to continue. 
The uses of these fields mil become apparent in the ensuing discussion. 

The space available for micromachine stacks In SRs 10362 and RCWS 10358 is dhrided Into two parts: 
Frames 27205 reserved for MOS 10370 and Frames 27206 available for the MIS 27203. Frames 27206 may 
contain no MIS Frames 27203, or be partially or completely occupied by MIS Frames 27203. Space which 

QQ contains no MIS Frames is Free Frames 27207, The size of the space reserved for Monitor Micromachine 
Stack Frames 27205 is fixed, and Spaces 27203, 27205, and 27207 always come in the spedfied order. 
Register Addressing 27011 handles addressing in Stack Portion 27201 of GRF 10354 and RCWS 10358 In 
such fashion that the values for the locations of current, previous, and bottom frames specifying registers 
in RCWS 10358 or frames in Stack Portion 27201 automatically "wrap around" when they are incremented 

eg beyond the largest index value allowed by the sizes of the registers or decrenriented below the smallest 
index value. Thus, though Spaces 27203, 27205, and 27207 always have tiie same relative order, their GRF 
10354 franms and RCWS registers may be located anywhere in Stack Portion 27201 and RCWS 10358. 

« 2. Microroutine Invocations and Returns , . ^ r-e miin 

In CS 10110. microroutines may be invoked by other microroutines or by signals from tS,lono 
hardware. The methods of invocation aside, microroutine invocations and returns resemble Invocations or 
and returns from procedures written in high-level languages. In die following, the general principles ot 
microroutine invocations and renirns are discussed, and thereafter, the specific methods by which 

^ microroutines may be Invoked in CS 10110. The differences between Invocations in monitor mode and 
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invocations in virtual mode are explained in the detailed discussions of the two modes. 

The microroutine which is currently being executed runs on the frame specified by Current Pointer 
2721 5, When an invocation occurs, either because the executing microroutine performs a call, or because a 
signal which causes invocations has occunredi JP 10114 hardware does three things: 
5 — It stores state Information for the invoking microroutine in the RCWS 10358 register associated with the 

current frame. The state information includes the location at which execution of the invoking 

microroutine will resume, as well as other state information. 
— It increments Current Pointer 2721 5 and Previous Pointer 27213, thereby providing a frame for the new 

invocation. 

w — It begins executing the first instruction of the newly invoked microroutine. 

Because the newly-invoked microroutine can access registers of the invoking microroutine's frame, the 
invoking microroutine can pass "arguments" to the invoked microroutine by placing values in registers in 
Its frame used by the invoked microroutine. However, the involdng microroutine cannot specify which 
registers contain "arguments'* on an invocation, so the invoked microroutine must know which registers of 

fs the previous frame are used by the invoking microroutine. Since the only "arguments" which a 
microroutine has access to are those in the previous frame, a microroutine can pass arguments which it 
received from its Invoker to a microroutine which it invokes only by copying the arguments from its 
invoker'S frame to its own frame; which then becomes the newly-invoked routine's previous frame. 
The return is the reverse of the above: Current Pointer 27215 and Previous Pointer 27213 are 

20 decrenr^nted, thereby "popping off" the finished invocation's frame and returning to the invoker's frame. 
The invoker then resumes execution at the location specified in the RCWS 10358 register and using the 
state saved in the RCWS 10358. The saved state includes the value of the Condition Code in IVtCWI 20230 at 
the time of the invocation and flags indicating various pending Events. The Condition Code field in MCW1 
20290 is set to the saved value, and the pending event flags may cause Events to occur as described in 

29 detail below. 



3. Means of Invoking Microroutines 

In the micromachine, invocations may be prccfciced ^her by commands in microinstructions or by 

30 hardware signals. In the following, invocations produced by commands in microinstructions are termed 
Calls, while those produced by hardware s^nals are termed Event Invocations and Jams. Invocations are 
further distinguished from each other by the locations to which they return. Calls and Jams return to the 
microinstniction following the microinstruction in which the invocation occurs; Event invocations retum to 
that microinstruction, which is then repeated. 

35 _ In terms of implementation, the different retum locations are a consequence of the point in the 
micrcHnachine cyde at whiph Calls, Jams, and Event invocations save a retum location and transfer control 
to the called routine. WHh Calls and Jams, these operations are performed in the Ml cyde; with Event 
invocations, on the other hand, the Event signal during the MO cyde causes die MO cycle to be followed by 
a MA cyde Instead of the Ml cyde, and the operations are performed In the MA cyde. In the Ml cyde, the 

40 value in mPC 20276 is incremented; in the MA cyde, it is not Consequently, the return value saved in 
RCWS 10358 on a Call or Jam is the incremented value of mPC 20276, while the retum value saved on an 
Event invocation is the unincremented value of mPC 2027a The following discussion will deal first with 
Calls and Jams, and then with Event invocations. 

A Call command in a microinstruction contains a literal value which specifies the offset from the 

45 microinstruction containing the Call at which ex«xition is to continue after the Call. When the 
microinstruction with the Call command is executed in nmcromachine cyde M1, BRCASE 20278 adds the 
offset contained in the command to the current value of mPC 20276 in order to obtain the location of the 
Invoked microroutine and sets SITTNAS 20286 to select the location provided by BRCASE 20278 as the 
location of the next microinstruction. Then the Call command increments mPC 20276 and stores the 

so incremented value of mPC 20276 in tiie RCWS 10358 register assodated with the current frame in SRs 
10362 and increnrients Current Pointer 27215 and Previous Pointer 27213 to provide a new frame in SRs 
10362. The Jam works exactly like the Call, except that a hardware signal during micromachine cyde Ml 
causes the actions associated with the invocation to occur and provides the location of the invoked 
microroutine directiy to SfTTNAS 20286. 

SB With Events, Event Logic 20284 causes an invocation to occur during cyde MO and provides the 

location of the invoked microroutine via CSAOR 20299. Since the Evem occurs during cyde MO, the location 
stored in RCWS 10358 is the unincrememed value of mPC 20276. and SITTNAS 20286 selects the location 
provided by Event Logic 20284 as the location of the next microinstniction. Since the return from the Event 
causes the microinstruction during which the Event occurred to be re-executed, the microinstruction and 

so the microroutine to which ft belongs may be said to be "unaware" of the Event's occurrence. The only 
difference between the execution of a microinstruction during which an Event occurs and the execution of 
the same microinstruction without the Event is the length of time required for the «cecutton« 
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4. Occurrence of Event Invocations (Fig, 273) 

As descnbed previously. Event Invocations are produced by Event Logic 20284. The ideation in 
microcode to which Event Logic 20284 transfers control is determined by the following: 

— The operation being commenced by RJ 10120. Certain Event Invocations may occur only at the 
5 ' beginning of certain FU 10120 operations. 

— The state of Event signal lines from hardware and internal registers in Event Logic 20284. 

^ The state of certain registers visible yna MCW1 20290. Some of these registers enable Events and 
others mask Events. Of the registers which enable Events^ some are set by Event signals and others by 
the microprogram. 

10 — On returns from invocations of microrouttnes, the settings of certain bits In the RCWS 10358 register 
belonging to the micromachlne frame for the invocation that is being returned to. 
Microprograms may use these mechanisms to disable Event signals and to delay an Event invocation 
from an Event signal for a single microinstruction or an indefmrte period, and FU 10120 uses them to 
BUtomaitically delay Event invocations resulting from certain Event signals. Using traditional programming 
terminology, the mechanisms allow a differential masking of Event signals. An Event signal may be 
expildtly madced for a single microtnstrucUon, it may be masked for a sequence of microinstructions; it 
may be automatically ma^ed until a certain operation occurs, or It may be automatically masked for a 
certain maximum length of time. Event signals vv^ich occur while they are masked are not lost. In some 
cases, the Event signal continues until it is serviced; in others^ a register is set to retain the fact that the 
20 Event signal occurred. When the Event signal Is unmasked, the set register causes the Event signal to 
reoccur. In some cases, finally, the Event signal is not retained, but recurs when the microinstruction vtrhich 
caused rt is repeated. 

In the following, the relationship between FU 10120 opennions and Event signals is first presented, and 
then a detailed discussion of the enabling registers in MCW1 202S0 and of the bits in RCWS 10358 registers 

^ whidi control Event invocations. 

FU 10120 allows Event invocations resulting from Evem signals to be Inhibited for a single 
microinstruction; it also delays certain Event Invocations for certain Event signals until the first 
micrtMnstruction of an SIN. Other Event signals occur only at the beginning of an SIN, at the beginning of a 
Namespace Resolve or Evaluate operation, or at the beginning of a logical memory reference. 

30 Event Invocations may be delayed for a single microinstruction by setting a field of the 
microinstruction Hsetf. Setting this field delays almost ail Event invocations, and thereby guarantees that 
an Event invocation will not occur during the microinstruction's MO cycle. 

Event signals relating to ctebugging occur at the beginnings of certain mlcrom^lne operations. Such 
Event signals are called Trace Event signals. As will be explained In detail, in the discussion of the 

35 debugger. Trace Event signals can occur on the first microinstructipn of an SIN, at the beginning of an 
Evaluate or Resolve operation, at the beginning of a loglcaf memory reference, or at the beginning of a 
microinstnjction. iPM interrupt signals and Interval Timer Overflow Ev^t signals are automatically masked 
until the beginning of the next SIN or until a maximum amourit of time has elapsed, vi^lch ever occurs first. 
The mechanisms involved here are explained in detail in the discussion of interrupt handling in the FU 

40 10120 micromachine. 

Turning now to the registers used to mask and enable Event signals, Rg. 273 is a representation of the 
masking and enabling registers in MCW1 20290 and of the field In RCWS 10358 registers which controls 
Event invocations. Beginning with the registers in MCW1 20290, there are three registers which control 
Event invocations; Event Mask Register {EM\ 27301, Events Pending Register (EP) 27309, and Trace Enable 

4S Register iJE) 2731 9. Bits in EM 27301 mask certain Event signals as long as they are set; bits In EP Register 
27309 record the occurrence of certain Event signals while they are masked; when bits in TE Register 2731 9 
are set, Trace Event signals occur before certain FU 10120 operations. 

EM 27301 contains three one bit fidds: Asynchronous Mask Field 27303, Monitor Mask Field 27305, 
and Trace Event Mask Field 27307. As explained in detail in the discussion of BJ 10120 hardware, these bits 

so establish a hierarchy of Event masks. If Asynchronous Mask Field 27303 is set, only two Event signals are 
masked: that resulting from an overflow of EGGTMR 25412 and that resulting from an overflow of EU 
10122's stack. If Monitor Mask Field 27305 is set, those Events are masked, and additionally, the FU Stack 
Overflow Event signal is masked. As will be explained in detail later, when the FU 10120 Stack Overflow 
Event signal is masked, the FU micromachine is executing in monitor mode. If Trace Event Mask Field 

ss 27307 is set, Trace Trap Event signals are masked in addition to the above mgnals. Each of the fields in EM 
27301 may be individually set and cleared by the microprogram. 

Four Event signals set fields in EP 27309: the EGGTMR 25412 Runout signal sets ET Reld 27311, tiie 
INTTMR 25410 Runout signal sets IT Field 27313, the Non-Fatal Memory En-or signal sets ME Reld 27315, 
and tiie Inter-Process Message signal sets IPM Field 27317. Event invocations for all of these Event signals 

eo but the Egg Timer Runout signal occur at the beginning of an SIN; in these cases the fields in EP 27309 
retain the fact that the Event signal has occurred until that time; tfie Event invocation for the Egg Timer 
Runout signal occurs as soon after the signal as the settings of mask bits in EM 27301 allow. The bit in ET 
Field 27311 retains the feet of the Egg Timer Runout signal until the masking allows the Event invocation to 
occur. All of the fields in EP 27309 but ME field 27315 may be reset by microcode. The microroutines 

65 invoked by the Events must reset the appropriate fields; otherwise, tiiey will be relnvoked when they 
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return. ME Reld 27315 is automatically reset when the memory error is serviced, 

TE Register Field 27319 enables tradng. Each bit in the register enables a kind of Trace Event signal 
when It is set Depending on the kind of tracing, the Trace Event signal occurs at the beginning of an SIN, at 
the beginning of a Resolve or Evaluate operation, at the beginning of a logical memory reference, or at the 

5 beginning of a microinstruction. For details, see the following description of debugging. 

Turning now to the registers contained in RCWS 103K, each RCWS Register 27322 contains eight 
fields which control Event signals. The first field is FM Reld 27323. HA Reld 27323 reflects the value of a 
register in Event Logic 2Q2B4 when the invocation to virhich RCWS Register 27322 belongs occurs. The 
register in Event Logic 20284 is set only when the mtcroinstruction currently being executed is the first 

10 mtcroinstruction of an SIN. Thus, FM Reld 27323 is set only in RCWS Registers 27322 belonging to Event 
invocations which occur in the MO cyde of the first microinstruction In the SIN, i.e., at the beginning of the 
SIN. The value of the register in Event Logic 20284 Is saved in FM Reld 27323 because several Event 
invocations may occur at the beginning of a single SIN. The Event invocations occur In order of priority: 
when the one with the highest priority returns, the fact that FM Reld 27323 is set causes the register in 

IS Event Logic 20284 to again be set to the state which it has on the first microinstruction of an SIN. The 
register's stale, thus set, causes the next Event invocation which must occur at the beginning of the SIN to^ 
take place. After ail suc^ Invocations are finished, the first microinstruction enters its Ml cycle and resc^* 
the register in Event Logic 20284. In its reset state, the register inhibits all Event invocations which may 
occur only at the beginning of an SIN. It is again set at the beginning of the next SIN. 

20 The remaining fields in RCWS Register 27322 which control Event invocations are the fields in Return 
Signals Reld 27331. These fields allow the information that an Event signal has occurred to be retained 
through Event invocations until the Event signal's Event invocation takes place. When an invocation occurs, 
these fields are set by Event Logic 20284. On return from the invocation, the values of the fields are input 
into Event Logic 20284, thereby producing Event ^gnals. The Event signal vwtfi the highest priority results 

25 in an Event invocation, and the remaining Event signals set fields in Return Signals RM 27331 belonging 
to RCWS Register 27322 belonging to the invocation which is being executed when the Event signals occur. 
Because the fields in Return Signals Reld 27330 are input into Event Logic 20284, microcode invoked as a 
consequence of Event signals wMch sets one of these fields must reset the field itself. Otherwise, the return 
from the microcode will simply result in a reinvocation of the microcode. 

30 The seven fields in Return Signals Reld 27330 have the following significance: 

— When EG Reld 27333 is s^ an EU 10122 dispatch operation produced an illegal location in £U 10122 
microcode EUSiTT 20344. r*- 

— When NT Reid 27335, ST FWd 27341, mT Reld 27343, w mB Raid 27345 is set, a trace signal has 
occurred. Thes e are e xplained in detail in the discussion of digging. 

3S — When ES Reld 27337 is set, an EU 10122 Storaback Exception has occurred, i,e., an error occurred 
when EU 10122 attempted to store the result of an operation in MEM 10112. 

— When MRR Reld 27339 Is set a condition such as an ATU 10228 miss or a Protection Cacbe 1 0234 miss 
has occurred, and it is necessary to reattempt a memory reference. 

40 

d. Virtual Micromachines and the Monitor Micromachtne 

As previously described, microcode being executed on FU 10120'$ micromachine can run in either 
monitor mode or virtual mode. In this portion of the discus^'on, the distinguishing features and 
applications of the two modes are explained in detail. 



1. Virtual Mode 

As previously mentioned, the chief distinction between virtual mode and monitor mode is MIS 1036& 
The fact that MIS 10368 is of essentially uniimfted size has the following consequences for microroutines 
which execute In virtual mode. 

— An Invocation of a microroutine exemiting in virtual mode may have as its consequence further 
invocations to any depth. 

— Any invocation of or return from a microroutine executing in virtual mode may cause a page fauH 
The FU micromachine is in virtual mode when all bits in the Event Maslcs portion of MCW1 20290 are 

gs cleared. In this state, no enatiled Event signals are maslced, and Event invocations may occur In any 

microinstruction which does not itself masic them. 

Because invocations may occur to any depth in virtual mode< mio-oroutines executing in this mode 

may be recursive. Such recursive microroutines are especially useful for the Interpretation of Names. 

Often, as previously described, the Name Table Entry for a Name will contain Names which resolve to other 
^ Names, and the virtual micromachine's limitiess stack allows the use of recursive Name Resolution 

microroutines in such situations. Recurdve microroutines may also be used for complex SINs, such as 

Calls. 

Because invocations can occur to any depth, any numlier of Events may occur while a microroutine is 
executing in monitor mode. This in tum greatly simplifies Event handling, if an Event signal joccurs while an 
^ Event with a ghwn priority is being handled and the Event being signalled has a higher priority than the one 
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being handled, the result is simply the Invocation of the new Events handler. Thus, tfie order in which the 
Event handlers finish corresponds exactly to the priorities of their Events: those with the highest finish first 

A page fault may occur on any microin vocation or return executed in virtual mode because an 
invocation in virtual mode which occurs when there are no more Free Frames 27207 on SRs 10362 causes 
an Event signal which invokes a microroutine running In monitor mode. The microroutine transfers MIS 
Frames 27203 from GRF 10354 to Secure Stack 10336 in MEM 101 12, and the transfer may cause a page 
feult. Similariy, when a microretum takes place from the last frame on MiS Frames 27203 on SRs 10362, an 
Event signal occurs which invoices a microroutine that transfers additional frames from Secure Stack 10336 
to GRF 10354, and this transfer, too, may cause a page fault. 

The fac^ that page faults may occur on microinvocations or microretums in virtual mode has two 
important consequences: microroutines which cannot tolerate page faults other than those explicitly 
generated by the microroutine Itself cannot execute in virtual mode, and because unexpected page faults 
cause execution to become indeterminate, microroutines which must run to completion cannot ^ecute in 
virtual mode. For example, If the microroutine which handles page feults executed In virtual mode« its 
Invocation could cause a page feult, whlf^ would cause the microrcnitine to be invoked again, which would 
cause another page fault, and so on through an infinite series of recursions. 

Z Monitor Mlcromachine 

As previously described, the essential feature of monitor mode is MOS 10370. In a present 
embodiment of CS 10110, this stack has a fixed minimum size, and Is always contained In GRF Registers 
10354. The nature of MOS 10370 has four consequences for microroutines which execute In monitor mode: 

— When the mlcromachine Is in monitor mode, the depth of invocations is limited; recursive 
microroutines therefore cannot be executed in monitor mode, and Event invocations must be limited. 

— Invocations of microroutines or returns from microroutines in monitor mode never result In page 
faults. 

— Microroutines executing In monitor mode are guaranteed to run to completion If they do rK>t suspend 
the Process 610 which they are ^ecuting or perform a Call to sofhA^are. 

— When the mlcromachine is executing In monitor mode, it Is guaranteed to return to virtual mode within 
a reasonable period of time, either because a microroutine executing in monitor mode has run to 
completion, or because the microroutine has suspended the Process 610 which it is executing, or has 
made a Call to sofhnfa re. The result m both cases is the execution of a new sequence of SOPs, and thus 
a return to virtual mode. 

In a present embodiment of CS 101 10, the FU mlcromachine is in monitor mode when a combination of 
masking bits in MCW1 20290 is set which results in the masking of the FU Stack Overflow Event and the Egg 
Timer Overflow Event..As previously described, these Events are maslced if Relds 27303, 27305, or 27307 is 
set, These Events and the consequences of masking them are explained In det^l below. 

The event signal for the FU Stack Overflow Event occurs on mk:rolnvocaiions for M^tdh there Is no 
frame available in MIS Frames 27203. If the Event signal is not masked, h causes the Invocation of a 
microroutine which moves MIS Frames from MIS Frames 27203 onto a Process 610'8 Secure Stack 10336. 
When the FU Stack Overflow Event is masked, all frames in SRs 10362 of GRs 10360 are available for 
microroutine invocations and microroutine invocations will not result in page feulls, but if the capadty of 
SRs 10362 is exceeded, FU 10120 ceases operation. ' 

The Egg Timer Overflow event signal occurs when Egg TMR ^12 runs out As will be explained In 
detail later. Egg TMR 25412 ensures that an Interval Timer Runout, an Inter-processor Message, or a Non- 
fatal Meniory Error wilt be serviced by JP 101 14 within a reasonable amount of time. If an Interval Timer 
Runout Event signal or an Inter-processor Message Event signal occurs at a time when it Is inefficient for 
the FU mlcromachine to handle the Event Egg TMR 2S412 begins njnning. When Egg TMR 2541 2 runs out 
the Event is handled unless the mlcromachine Is in monitor mode. If the Egg TMR 25412 Runout Event 
signal occurs while the FU mlcromachine is In monitor mode, i.e., while the Event Is masked, the Event 
signal sets Field 27311 In MCW1 20280, When the FU mlcromachine reverts to virtual mode, i.e., virtien all 
Event Mask bits in MCW1 20290 are cleared, the Egg TMR 25412 Runout Event occurs, and the Interval 
Timer Runout Inter-processor Message Event handlers are invoked by Event Logic 20284. 



e. Interrupt and Fault Handling 
1. General Principles 

Any computer system must be able to deal with occurrences which disrupt the normal execution of a 
program. Such occurrences are generally divided into two classes: faults and inienojpts. A fault occurs as a 
consequence of an attempt to execute a machine instruction, and its occurrence is therefore synchronous 
with the machine Instruction, Typical faults are floating point overflow faults and page faults. A floating 
point overflow fault occurs when a machine instruction attempts to perform a floating point arithmetic 
operation and the result exceeds the capacity of the CS 101 10's floating point hardware, that is EU 101 22. A 
page fault occurs when a machine instruction In a computer system with virtual memory attempts to 
reference data which is not presently available in the computer system's primary memory, that Is MEM 
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10112. Since faults are synchronous wtth the execution of machine instructions and in many cases the 
result of the execution of specific machine instructions, their occurrence is to some extent predictable. 

The occurrence of an interrupt is not predictable. An interrupt occurs as a consequence of some action 
taken by the computer system which has no direct connection with ^e execution of a machine instruction 
by the computer system. For example, an I/O interrupt occurs when data transmitted by an I/O device (tOS 
10116} reaches the central processing unit (FU 10120), regardless of the machine instruction the central 
processing unit is currentiy executing. 

In conventional systems, interrupts and faults have been handled as follows: if an interrupt or fault 
occurs, the computer system recognizes the occurrence before it executes the next machine instruction and 
executes an interrupt-handling mtcroroutine or Procedure ^2 Instead of tiie next machine instruction. If 
the interrupt or fault cannot be handled by the Process 61 0 in which it occurs, the interrupt or fault results in 
a process swap. When the interrupt harwlling routine is finished. Process 610 which faulted or was 
interrupted can be returned to the CPU rf it was removed and the next machine instruction executed. 

While -the above method works wefl with faults, the feet that interrupts are asynchronous causes 
several problems: 

— Machine instructions cannot require an indefinite amount of time to execute, since interrupts cannot be 
handled until the machine instruction during which they occur is finished. 

— It must be possible to remove a Process 610 from the CPU at any time, since the occurrence of an 
interrupt is not predictable. This requirement greatiy increases the dtfnculty of process management 

The method used for interrupt and fault handling In a present embodiment of CS 10110 is described 
below. 

2. Hardware Interrupt and Fault Handling in CS 10110 
In CS 10110« there are two levels of Interrupts: those which may created and dealt with completely tyy 

software, and those which may created by hardware signals. The fonner dass ol interrupts is dealt with in 
the discussion of Processes 610; the latter, termed hardware intmipts, is discussed below. 

In CS 10110, hardware interrupts and faultts begin as invocations of mfcroroutines In FU 10120. The 
invocations may be the result of Event signals or may be made by microprograms. For example, when lOS 
10116 places data In MEM 10112 for JP 10114, an Inter-processor Message Event signal results, arxi the 
signal causes the imracation of Inter-i^rooessor Message Interrupt handler microcode. On the odier hand, a 
Page Fault begins as an invocation of Page Fault microcode by LAT microcode. The actions taken by the 
microcode which begins handling the fault or intenrupt depend on whether the tault or interrupt is handled 
by the Process 610 which was beii^ executed when the fault or Event occurred or by a special KOS Process 
610. 

In the first case, the Event microcode may perform a Mlcrocode-to-Soflware Call to a high-level 
language procedure which handles the Event. An example of an Event handled in this fashion is a floating 
point overflow: when FU 10120 microcode determines that a floating point overflow has occurred, it 
invokes mtcrocode which may invoke a floating point overflow procedure provided by the high-level 
language whose S-Language was being executed when the overflow occurred. In alternate embodiments 
^ of CS 10110, the overflow procedure may also be in microcode. 

in the second case, the microcode handling the fault or Interrupt puts information In tables used by a 
KOS Process 61 0 which handles the fauH or interrupt artd then causes the KOS Process 610 to run at some 
later time by advancing an Event Counter awaited by the Process 610. Event Counters and the operations 
on them are explained in detail in a following description of Processes 610. Since the tables and Event 
^ Counters manipulated by microcode are always pr^ent In MEM 101 12, these operations do not cause page 
faults, and can be performed in monitor mode. For example, when lOS 10116 transits an IPM Event signal 
to JP 10114 after lOS 10116 has loaded data Into MEM 10112, the Event resulting from the Event signal 
invokes microcode v^lch examines a queue containing messages from lOS 10116. The messages In the 
queue contain Event Counter locations, and the microcode which examines the queue advances those 
^ Event counters, thereby causing Processes 610 which were waiting for the data returned by the I/O 
operation to reoomntence execution. 

3. The Monitor Mode, Differential Masking and Hardware Interrupt Handling 

FU 10120 micromachine's monitor mode and differential masking facilities allow a method of 
ss hardware interrupt handling which overcomes two problems assodated with conventional hardware 
interrupt iiandling: an interrupt can be handled in a praiictable amount of time regardless of the amount of 
time required to execute an SIN, and rf the microcode which handles the interrupt executes in monitor 
mode, the Interrupt may be handled at any time without unpredictable consequence. There are two 
sources of hardware interrupts in CS 10110: an Inter-Processor Message (IPM) and an Interval Timer 25410 
€0 Runout. An IPM occurs when lOS 101 16 completes an I/O task for JP 10114 and signals completion of tiie 
task via lOJP Bus 10132. An Interval Timer Runout occurs when a preset time at which CS 101 10 must take 
some action is reached. For example, a given Process 610 may have a limit placed on the amount of time it 
may execute on JP 101 14. As is explained in a following description of process synchronization, the virtual 
processor management system sets Interval Timer 25412 to run out when Process 610 has used all of the 
^ time available to it 
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Both IPMs and Interval Timer Runouts begin as Event signals. The immediate effect of the Event signal 
Is to set a bit in EP Field 27309 of MCWl. In principle, the set bit can cause invocation of the event 
microcode for the Event on the next MO cycle in which the FU 10120 micromachine is in virtual mode. Since 
microroutines running in monitor mode are guaranteed to return the micromachine to virtual mode within 
a reasonable length of time, and the Event invocation will occur when this happens, the Event is 
guaranteed to be serviced in a reasonable period of time. The microroutines Invoked by the Events 
themsehres execute in monitor mode, thereby guaranteeing that no page faults will occur while they are 
executing and that Process 610 which is executing on JP 10114 when the hardware Intenrupt occurs need 
not be removed from JP 10114. 

While hardware interrupts are serviced In principle as described above, considerations of efficiency 
require that as many hardware interrupts as possible be serviced when the size of the FU micromachine's 
stack is at a minimum, i.e„ at the beginning of an SlN's execution. This requirement is achieved by means 
of Egg TMR 25412 and ET Rag 27311 in MCWl 20290. As described above, when an IPM interrupt or an 
inten^ai Timer 25410 Runout interrupt occurs, Reld 27317 or 27313 respectively is set in MCWl 20290. At 
the same time, Egg TMR 25412 begins running. If the current SlN's execution ends before Egg TMR 25412 
runs out the set Field in MCWl 20230 causes the Interval Timer Runout or Inter-processor Message Event 
invocations to occur on the first microinstruction for the next SIN. If, on the other hand, the currem SlN's 
execution does not end before Egg TMR 25412 runs out the Egg Timer Runout causes an Event signal. The 
immediate result of this signal is the setting of ET bit 2731 1 1n MCWl 20290, and the setting of ET bit 2731 1 
in turn causes the Interval Timer Runout Event invocation and/or IPM Event Invocation to take place on the 
next MO cyde to occur while the micromachine Is in virtue! mode* The above mechanism thus guarantees 
that most hardware interrupts will be handled at the begi nning of an SIN, but that hardware interrupts will 
always be handled within a certain amount of time regardless of the length of time required to execute an 
SIN. 



g. FU Micromachine and CS 10110 Subsystems 

The subsystems of CS 101 10, such as the object subsystem, the process subsystem, the S-tnterpreter 
subsystem, and the Name Interpreter subsystem, are implemented all or in part in the micromachine. The 
description of the micromachine therefore closes with an overview of tte relationship between these 
^ subsystems and the micromachine. Detailed descriptions of the operatrcMi of the subs^tems have been 
presented previously. 

The subsystems fall into three main groups: KOS subsystems, the Name Interpreter subsystem, and 
ttie S-lnterpreter subsystem. The relationship between the three is to some extent hierarchical: the KOS 
subsystems provide the environment required by the Name interpreter subsystem, and the Nante 

^ Interpreter subsystem provides the en^ronment required by the S-lnterpreter subsystem. For example, the 
S-interpreter subsystem interprets SINs consisting of SOPs and Names; the Name Interpreter suteystem 
translates Names into logical descriptors, using values called ABPs to calculate the kxations contained in 
the logical descriptors. The KOS subsystems calculate the values of the ABPs, translate Logical Descriptors 
27116 into physical MEM 1 01 12 addresses, and check whether a Process 61 0 has access to an object which 

^ it is refierencing. 

In a present embodiment of CS 10110, the Name Interpreter sut)system and the S-lnterpreter 
subsystem are implemented completely in the micromachine; in other embodiments, they could be 
implemented in high-level languages or in hardware. The KOS subsystems are implemented In both the 
micromachine and in high-level language routines. In alternate embodiments of CS 10110, KOS 

^ subsystems may be embodied entirely In microcode, or in high-level language routines. Some high-level 
language rautines may execute in any Process 610, while others are executed only by special KOS 
Processes 610. The KOS subsystems also differ from the others in the manner in which the user has access: 
with the S-lnterpreter subsystem and the Name Interpreter subsystem, the sut>systems come into play only 
when SINs are executed; the subsystems are not directly visible to users of the system. Portions of the KOS 

^ subsystems, on the other hand, may be expllcitiy invoked in high-level language programs. For example, 
an invocation in a high-level language program may cause KOS to bind a Process 610 to a Virtual Processor 
612. 

The following will first list the functions performed by the subsystems, and then relate the subsystems 
to the monitor and virtual micromachine modes and specific micromachine devices. KOS subsystems 
^ perform the following functions: 

— Virtual memory management; 

— Virtual processor management; 

— Inter-processor communication; 

— Access Control; 

60 — Object management; and, 

— Process management 

The Name Interpreter performs the following functions: 

— Fetching and parsing SOPs, and 

— Interpreting Names. 

es The S-interpreter, finally, dispatches SOPs, he., locates the FU 10120 and EU 10122 microcode which 
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executes the operation corresponding to a given SOP for a given S-Language. 

Of these subsystems, the S-tnterpreter, the Name Interpreter, and the microcode components of the 
KOS process and object manager subsystems execute on the virtual micromachlne; the microcode 
components of the remaining KOS subsystems execute on the monitor micromachine. As will be seen in 
^ the discussions of these subsystems, subsystems which execute on the virtual micromachine may cause 
Page Faults^ and may therefore reference data located anywhere in memory: subs^ems which execute on 
the monitor micromachine may not cause Page Faults, and the data bases vyhich these subsystems 
nnanipulate must therefore always be present at known locations in MEM 10112. 

The relationship between subsystems and RJ 10120 micromachine devices Is the following: 
Microcode for all subsystems uses DESP 20210, Microcode Addressing 27013, and Register Addressing . 
27011, and may use EU Interface 27007. S-lnterpreter microcode uses SOP Decoder 27003, and Name 
Interpreter Microcode uses Instruction Stream Reader 27001, Parsing Unit 27005, and Name Translation 
Unit 27015. KOS virtual memory management microcode uses Memory Reference Unit 27017, and 
Prote<^on Microcode uses Protection Unit 27019. 
'ff Having described in detail the structure and operation of CS 101 ICs major subsystems, MEM 101 12, 
FU 10120. EU 10122. lOS 10116, and DP 10118, and the CS 101 10 micromachine, CS 10110 operation will be 
described in further detail next below. Rrst operation of CS 101 10's Namespace, S-interpreter, and Pointer 
Systems will be described. Then, operation of CS 101 10 will be described in further detail with respect to CS 
10110*5 Kernel Operating System. 

20 

3. Namespace, S-lnterpreters, and Pointers iPigs. 301—307, 274) 

The prececfing chapters have presented an overview of CS 101 10, examined its hardware in detail, and 

explained how the FU 10120 hardware functions as a micromachine which controls the acthrities of other 

CS 10110 components. In the remaining portions of the specification, the means are presented by whidi 
25 certain key features of CS 10110 are implOTiiented using the hardware, the micromachine, tables in 

memory, and high-level language programs. The present chapter presents three of these features: the 

Pointer Resolution System, Namespace, and the S-interpreters. 

The Pointer Resolution System translates pointers, i.e.« data hems which contain location Information, 

into UID-of^ addresses. Namespace has three main functions: 
^ — It locates SINs and fetches them from CS 10110*3 memory into FU 1012a 

— tt parses SINs into SOPs and Nannes. 

— It translates Names into Logical Descriptors 271 16 or values. 

The S-interpreters decode S-opmtions reoeh^ed from namespace into locations in microcode contained In 
FUSnr 11012 and EUSfTT 20344 and then execute that microcode* If the S-operations require operands, 
3S the S-interpreteis use Namespace to translate the operands into Logical DescriptoiB 27116 or values as 
required by the operations. 

Since Namespace depends on the Pointer Resolution System and the Snnterpreters depend on 
Namespace, the discussion of the systems begins with pointers and then deals wrth namespace and S- 
intopreteis. 

40 

A. Pointers and Pointer Resolution (Rgs. 301, 302) 

A pointer is a data item which represents an address, i.e., in CS 10110, a UIOK>ffeet address. CS 101 10 
has two large classes of pointers: resolved pointers and unresolved pointers. Resoh^d pointers are 
pointers whose values may be immediately interpreted as UID-offset addresses; unresoh/ed pointers are 
4S pointers whose values must be Interpreted by high level language routines or microcode routines to yield 
UID-oliiset addresses. The act of interpreting an unresolved pointer is call^ r^olving It. Since the manner 
in which an unresolved pointer is resotved may be determined by a high^evel language routine written by 
a system user, unresoh/ed pointers provide a means by which users of the system may define tiieir own 
pointer types. 

so Both resolved and unresolved pointers have subclasses. The subclasses of resoh^d pointers are UID 
pointers and object relative pointers. UID pointers contain a UID and offset, and can thus represent any CS 
101 10 address; object-relative pointers contain only an offset; the address's UIO is assumed to be the same 
as that of the object containing the object-relative pointer. An object-relative pointer can therefore only 
represent addresses in the object which contains the pointer. 

55 The sut)clas^ of unresolved pointers are ordinary unresolved pointers and associative pointers. The 
difference between the two kinds of unresolved pointers is the manr>er in which they are resolved. Ordinary 
unresoh/ed pointers are always resoh/ed by high-lev^ language routines, while associative pointers are 
resotved the first time they are u^d in a Process 610 and a domain by high-level language routines, but are 
subsequently resolved by means of a table called the Associated Address Table lAAT). This table is 

60 accessible to microcode, and associative pointers may therefore be more quickly resolved than ordinar/ 
unresoh^ pointers. 

The following discussion will first explain the formats used by all CS 10110 pointers, and will then 
explain how pointers are processed in FU 10120. 

65 
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a. Pointer Formats (Fig. 301) 

Figure 301 represents a CS 10110 pointer. The figure has two parts: a representation of General Pointer 
Fornnat 30101, which gives an overview of the fteids which appear in all CS 10110 pointers, and a detailed 
presentation of Rags and Format Field 3010^ which contains the information by which the Iclnds of CS 
10110 pointers are distinguished. 

Turning first to General Pointer Format 30101, all CS 10110 pointers contain 128 bits and are dhdded 
into three main fields: 

— Offset Field 30103 contains the offset portion of a UID-offset address in resolved pointers and in 
associative pointers; in other unresolved pointers, it may contain an offset from some point in an 
object or other information as defirted by the user. 

— Flags and Format Reld 30105 contains flags and fomnat codes which distinguish between kinds of 
pointers* These flags and format codes are explained in detail below. 

— UID field 30115 contains a UID in UIO pointers and in some associative pointers; in objectrelative 
pointers, and other associative pointers, Its meaning is undefined, and in ordinary unresohfed pointers, 
it may contain information as defined by the user. 

Flags and Format Field 30105 contains four subfields: 

— Fields 301 07 and 301 1 1 are reserved and mi^ be set to 0. 

— NR Reld 30109 indicates whether a pointer is resolved or unresolved. In resolved pointers, the field is 
set to 0, and in unresolved pointers, it is set to 1« 

20 — Format Code Reld 301 13 indicates the kind of resolved or unresolved pointers. Format codes for the 
presem embodiment are explained below. 

The values of Format Code Reld 30113 may range from 0 to 31. If Format Code Field 301 13 has the 
value 0, the pointer is a null pointer, i.e., a pointer which nei^er directly nor indirectly indicates an address. 
The meanings of the other format codes depend on the value of NR Reld 30109: 

2$ 

NR Field Value Format Code Value Meaning 
0 1 UiD pointer 

^ 0 2 Object*relative pointer 

0 all other codes Illegal 

1 1 UiD associative pointer 

35 

1 2 Ob]ect-r^ve 

associative pointer 

1 all other codes Ordinary unresoh/ed 

^ pointer 

As Indicated by ttie above table, the present embodiment has two kinds of associative pointer, UID 
associative potnteni and object-relatm associative pointers. Like a UID pointer, a UID associative pointer 
contains a UID and an offeet, and like an object-relative pointer, an object-relative associative pointer 
45 contains an offset and takes the value of the UID from the object to which It belongs. However, as will be 
explained In detail later, the UID and offset which the associative pointers contain or represent are not used 
as addresses. Instead, the UID and offset are used as tags to locate entries in the AAT, which associates an 
associative pointer with a resolved pointer. 

$0 fo. Pointers in FU 10120 (Rg. 302) 

When a pointer is used as an address in FU 10120, the address information in the pointer must be 
translated into a Logical Descriptor 271 16 consisting of an AON, an offset, and a length field of 0; when a 
Logical Descriptor 27116 in FU 10120 is used to fonm a pointer value in memory, the AON must be 
converted back to a UID. The first conversion is termed pointer-to-descriptor conversion, and the second 

ss descriptor-to-pointer conversion. Both corrversions are accomplished by microcodes executing in FU 
10120. 

What is involved In the translation depends on the kind of pointer: If the pointer (s a UID pointer, the 
UID must be translated into an AON; if the pointer is an object-relative pointer, the AON required to fetch 
the pointer is the pointer's AON, so no translation is necessary. If the pointer is an unresolved pointer, it 
eo niust first be translated into a resolved pointer and then into a Logical Descriptor 27116. If the pointer is 
associatwe, the translation to a resolved pointer may be performed by means of the ATT, 

in the present embodiment when other FU 10120 microcode calls poimer-to-descriptor microcode, the 
calling microcode passes Logical Descriptor 271 16 for the location of the pointer which Is to be translated 
as an argument to the pointer-to-description translation microcode. The pointer-to-descriptor microcode 
fis returns a Logical Descriptor 27116 produced from the value of the pointer at the location specified by 
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Logical Descriptor 27116 which the pointer-to-descriptor microcode received as an argument. 

The pointer-to-descriptor microcode first uses logical Descriptor 27116 given it as an argument to 
fetch the value of the pointer's Offset Field 30103 from memory. It then saves Logical Descriptor 271 16*5 
offset in the output register belonging to OFFALU 20242 and places the value of the pointer's Offset Field 
^ 30103 in the offset field of Logical Descriptor 27116 which it received as an argument The pointer-to- 
descriptor microcode then saves Logical Descriptor 27116 indicating the pointer's location by storing 
Logical Descriptor 27116's AON and offset {obtained from OFFALU 20242) In a register In the GRF 10354 
frame being used by the invocation of the pointer-to-descriptor microcode. Next, the microcode adds 40 to 
the offset stored in OFFALU 20242, thereby obtaining the address of NR Reid 30109, and uses the address 
to fetch and read NR Field 30109 and Format Code Field 30113. The course of further processing is 
determined by the values of these fields. K NR Field 30109 indicates a resolved pointer, there are four cases, 
as determined by the value of Format Code Field 30113: 

— Format code field = 0: The pointer is a null ixiinter. 

— Format code field 1: The pointer is a UID pointer. 

/5 — , Format code field = 2: The pointer is an intra-object pointer. 

— Any other value of the format code field: The pointer is Invalid. 

In the first case, the microcode sets all fields of the argument to 0; in the second, it fetches the value of 
UID Reld 301 15 from memory and Invokes LAR microcode (explained in the discussion of objects), which 
translates the UID to the AON associated with it. The AON Is then loaded into the arguments AON field. In 

20 the third case, the AON of Logical Descriptor 271 16 for the pointer's location and tiie pointer's AON are the 
same, so the argument already contains the translated pointer. In the fourth case, the microcode performs 
a call to a pointer f ault-handiing Procedure 602 which handles invalid pointer faults, passing saved Logical 
Descriptor 27116 for the pointer as an argument. Procedure 602 which handles the fault must return a 

^ resolved pointer to the microcode, which then converts it to a Logical Descriptor 271 16 as described above. 

a Descriptor to Pointer Conversfon 

Descriptor to pointer conversion is the reverse of pointer to descriptor conversion with resoWed 
poimers. The operation must be performed whenever a resolved pointer is moved from an FU 10120 

30 register Into MEM 10112. The operation takes two arguments: a Logical Descriptor 27116 which specifies 
the address to wrfiich the p<»n[ter is to be written, and a Logical Descriptor 27116 whose AON and offset 
fields specify the location contained In the pointer. There are two cases: intra-object pointers and UID 
poimers. Both kinds of painters have values In Offset Reld 30103, so the descriptor^o-polnter microcode 
first writes the second argumenfs offeet to location specified by the first argument's Logical Descriptor 

as 271 16. The next step is to determine whetfier the pointer is an intra-object pointer or a UID pointer. To do 
so, the microcode compares the arguments' AONs. If they are the same, the pointer points to a location in 
the object w^ich contains it and is therefore an intra-object pointer. Since UID Reld 301 15 of an intra-object 
pointer Is meaningless, the only step remaining for Intra-object pointers is to set Rags and Fonnat field 
30105 to the binary representation of 2, which sets all bits but bit 46 to 0, and thereby identifies the pointer 

40 as a resolved intra-object pointer. 

With UID pointers, the descriptor-to-pointer microcode sets Rags and Format Reld 30105 to 1 , thereby 
identtfying the pointer as a resoh«d UID pointer, and calls a KOS LAR microroutine (explained in detail in 
the cfiscussion of objects) which converts the first argument's AON to a UID and places the result UID in the 
current frame. When the KOS AON to UID conversion microroutine returns, the descriptor-to-pointer 

^ microcode writes the UID to the converted pointer's UID Reld 301 15. 

B. Namespace and the S-Jnterpreters {Rgs. 303--307) 

Namespace and the S-lnterpreter both interpret information contained In Procedure Objects 608. 
Consequently, the discussion of these components of CS 10110 begins with an overview of those parts of 
so Procedure Object 606 relevam to Namespace and the S-lnterpreters, and then explains Namespace and the 
Snnterpreters in detaiL 

a. Procedure Object «)6 Overview (Rg. 303) 

Rgure 303 represents those portions of Procedure Object 608. Fig. 303 expands information contained 

55 in Rg. 103; Relds which appear in both Rgures have triQ number of Rg. 103. Portions of Procedure Object 
608 which are not discussed here are dealt with later in the discussion of Calls and Returns. The most 
important part of a Procedure Object 608 for these systems is Procedure Environment Descriptor (PED) 
30303. A Procedure 602*5 PED 30303 contains the information required by Namespace and the S-tnterpreter 
to locate and parse Procedure 602's code and interpret its Names. A number of Procedures 602 in a 

60 Procedure Object 608 may share a PED 30303. As will be seen in the discussion of Calls, the fact that a 
Procedure 602 shares a PED 30303 with the Procedure 602 that Invokes It affects the manner in which the 
Call is executed. 

The fields of PED 30303 which are important to the present discussion are three fields in Header 30304: 
K Reld 303(», LN Reld 30307, and SIP Reld 30309, and three of the remaining fields: NTP Reld 3031 1 , SDPP 
& field ^13, and PBP Field 30315. 
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— K Field 30305 Indicates whether the Names in the SINs o1 Procedures 602 which share PED 30303 have 
8, 12. or 16 bits. 

— LN Field 30307 contains the Name which has the largest Index of any in Procedure 602's Name Table 
10350. 

5 _ SIP Reld 30309 Is a UID pointer to the object v^^ich contains the S-interpreter for Procedure 602's S- 

Language. 

— NTP Reld 30311 is an object-relative pointer to the beginning of Procedure 602*s Name Table 10350. 

— SDPP Reld 30313 is a pointer which is resolved to the location of static data used by Procedures 602 to 
which PED 30303 belongs when one of Procedures 0)2 Is invoked by a given Process 610. The resolved 
pointer corresponding to SDPP 30313 is the SDP ABP. 

— PBP Reld 3031 5 contains the PBP ABP for invocations of Procedures 602 to which PED 30303 belongs. 
The PBP ABP is used to calculate locations inside Procedure Object 608. 

Other areas of interest in Procedure Object 608 are Uterals 30301 and Static Data Prototype (SDPR) 
30317, Literals 30301 contains litera! values, l.e., values In Procedure 602 whidi are known at compile time 
and will not change during program execution. SDPR 30317 may contain any of the following : pointers to 
extemal routines and to static data contained In other objects, information required to create static data for 
a Procedure 60i and in some cases, the static data itself. Pointers in SDPR 30317 may be either resolved or 
non-resolved. 

in the present embodiment, Binder Area 30323 fs also important Binder Area 30323 contains 
5^ infortnation which allows unresolved pointers csontained in Procedure Object 608 to be resolved. 
Unresolved pointers other than SDPP 30313 In Procedure Object 608 all contain locations in Binder Area 
30323. and the specified location contains the information required to resohfe the pointer. 

Rg. 303 contains arrows showing the locations in Procedure Object 608 pointed to by IMTP Reld 3031 1 , 
SDPP Reld 30313, and PBP Reld 30315. NTP Field 3031 1 points to the beginning of Name Tables 10350, and 
^ thus a Name's Name Table Entry can be located by adding the Name's value to NTP Reld 3031 1. PBP Reld 
30315 points to the beginning of Uterals 30301, and consequently, the locations of Uterals and the 
. locations of SINs may be expressed as offsets from the value of PBP Reld 30315. SDPP Reld 30313 points to 
the beginning of SDPR 30317. As will be explained In det^l in the discussion of Calls, when a procedure 602 
has static data, the SDP ABP is derived from SDPP Reld 30313. 

30 

b. Name^aace 

The Namespace component of CS 101 10 locates SINs belonging to a procedure and fetches them from 
memory to RJ 10120, parses SINs into SOPs and Names, and performs Resoh/e and Evaluation operations 
. on Names. The Resolve operation trandates a Name Into a Logical Descriptor 27116 for the data 
35 represented by the Name, while the Evaluation operation obtains the data itself. The Evaluation operation 
does so by performing a Resoh^ operation and then using the resulting Logical Descriptor 271 16 to fetch 
the data. Since the Evaluation and Resoh^ operations are the most oomplica^, the discussion begins with 
them. 

40 1. Name Resolution and Evaluation 

Name Resolution and Evaluation translate Names into Logical Descriptors 27116 by means of 
information contained in the Names' NTEs^ and the NTEs define locations in terms of Architectural Base 
Registers. Consequentiy, the following discussion will first describe Name Table Entries and Architectural 
Base Pointers and then the means by which Namespace translates tiie information contained in the Name 

« Table Entries and Architectural Base Pointers into Logical Descriptors 271 16. 

2. The Name Table (Rg. 304) 

As previously mentioned. Name Tables 10350 are contained in Procedure Objects 608. Name Tables 
10350 contain the information required to translate Names into Logical Descriptors 271 16 for the operands 
60 represented by the Names. Each Name has as its value the number of a Name Table Entry. A Name's Name 
Table Entry is located by multiplying the Name's value by the size of a short Nanw Table Entry and adding 
the product to the value in NTP Reld 3031 1 of PED 30303 belonging to Procedure 602 which contains the 
SIN. 

The Name Table Entry contains length and type information for the data item specified by the Name, 

6 and represents the data item's location as a displacement from a known location, termed the base. The 
base may be a location specified by an ABP, a location specified by another Name, or a location specified 
by a pointer. In the latter case, the pointer's location may be specified in terms of an ABP or as a Name. 

Rg. 304 is a detailed representation of a Name Table Entry <NTE) 30401. There are two kinds of NTEs 
30401: Short NTEs 30403 and Long NTEs 30405. Short NTEs 30403 contain 64 bits; Long NTEs 30405 
69 contain 1 28 bits. Names that represent scaler data items whose displacements may be expressed in 16 bits 
have Short NTEs 30403; Names that represent scaler data items whose displacements require more than 
16 bits and Names that represent array elements have Long NTEs 30405. 
A Short NTE 30403 has four main fields, each 16 bits In length: 

— Rags and Format Reld 30407 contains flags and format information which specify how Namespace is 
65 to imerpret NTE 30401. 
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— Base Reld 30425 indicates the base to which the displacement is to be added to obtain the location of 
the data represented by the Name, Base Reld 30425 may represent the location in four ways: by means 
of an ABP by means of a Name, by means of a pointer located by means of an ABP, and by means of a 
pointer located by means of a Name. 

— Length Reld 30435 represents the length of the data. The length may be a literal value or a Name. If it is 
a Ndnr)e« the Name resolves to a location which contains the data item's length. 

— Displacement Reld 30437 contains the displacement of the beginning of the data from the base 
spedfled in ReJd ^}425. The displacement is a signed irtteger value. 

Long NTEs 30405 have four additional fields, each 16 bits long: Two of the fields. Index Nanr>e Reld 
30441 and lES Reld 30445 are used only in NTEs 30401 for Names that represent arrays. 

— Displacement Extension Reld 30439 is used in all Long NTEs 30405. tf the displacemem value in Reld 
30437 has less than 16 bits* Displacement Exten^on Reld 30439 contains sign bits, i.e., the bits in the 
field are set to 0 when the displacement is poadve and 1 when the displacement is negative. When the 
displacement value has more than 16 bits. Displacement Extension Field 30439 contains the most 
significant bits of the displacement value as virell as sign bits. 

— Index Name Reld 30441 contains a Name that represents a value used to index an dement of an array. 

— Reld 30443 is reserved. 

lES Rdd 30445 contains a Name or Literal that specifies the size of an element in an array. The value 
represented by this field is used together with the value represented by Index Name Reld 30441 to locate 
an element of an array. 

As may be seen from the above^ the following fields may contain names: Base Reld 30425, Length 
Reld 30435, Index Name Reld 30441, and lES Reld 30445. 

Two fields in NTE 30401 require further consideration: Rags and Format Reld 30407 and Base Reld 
30425. Rags and Format Reld 30407 has thfBe sul^elds: Rags Reld 30408, FM Reld 30421 , and Type Reld 
30423. Turrung first to Rags Reld 30408, the m flags in the field Indicate how Namespace is to interpret 
NTE 30401. The Hags have the fbllownng meanings when they are set: 
^ Long NTE Rag 30409: NTE 30401 tea Long NTE 30405. 

— Length Is a Name Rag 30411: Length Held 30435 contains a Name. 

— Base is a Name Rag 30413: Base Reld 30425 contains a Name instead of the number of an ABP. 

— Base Indirect Rag 3041 B: Base Held 30425 represents a pointer^ and the location represented by NTE 
30401 is to be calculated by obtaining the pointer's value and adding the vabie contahied In 
Displacemem Reld 30437 and Dtsplacement Extension Reld 30439 to the pointer's offset 

— Artsy Rag 30417: NTE 30401 represents an array. 

— lES is 8 Name Flag 30419: lES Field 30445 contains a Name that represents the lES value. 
Several of these flags nnay be set In a given NTE 30401 . For example, an entry for an array element ttiat 

was referenced via a pointer to tfie array which in turn was represented by a Name, and whose lES value 
was represented liy a Name, would have Flags 30409, 30413, 30415. 30417, and ^19 sel 

FM Field 30421 Indicates how the data represented by the Name is to be formated when It is fetched 
from memory. The value of FM Reld 30421 is placed in RU Reld 27107 of Logical Descriptor 27116 
produced from NTE 30401. The two bits allow for four possibilities: 

Setting Meaning 



00 right jusdfy, zero fill 

01 right justify, sign fill 

10 left justify, zero fill 

1 1 left justify, ASCII space fill 



The four bits in Type Reld 30423 are used by compilers for language-specific type information. The 
value of Type Reld 30423 is placed in Type Reld 27109 of Logical Descriptor 27116 produced from NTE 
30401. 

Base Reld 30425 may have either Base is an ABP Format 30427 or Base is a Name Format 30432. The 
manner in which Base Field 30425 is interpreted depends on the setdng of Base is a Name Flag 30413 and 
Base indirect Flag 30415. There are four possibilities: 
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Reld Settings 

Base IS a Name Base Indirect Meaning 

0 0 ABP Format locates base 

directty. 

0 1 ABP Format locates a pointer 

which is the base. 

1 0 Base ts Hatne Format locates 

base when Name Is resolved. 

1 ^ Base Is Name Format locates 

a pointer when Name is 
resolve and the pointer is *• 
the base. 

As indicated by the above table* Base Reld 30425 ts interpreted as having Base Is ABP Format 30427 
20 when Base is a Name Flag 30411 is not set In Base is ABP Format 30427, Base Reld 30425 has two 
subfields: ABP Reld 30429 and Pointer Locator Reld 30431. The latter field has meaning only when Base 
Indirect Hag 3041 S ts set ABP Reld 30429 is a two*bit code which Indicates the ABP. The settings and their 
meanings are the following: 

se Setting APB^ 



70 



ts 



00 FP 

01 Unused 

10 SDP 

11 PBP 



3s The ABP& are cfiscussed below. When Base Indirect Flag 30415 is set to 1 and Base Is a Name Flag 
30413 is set to 0* the rfsmatning 14 bits of the Base Reld in ABP Format are interpreted as Pointer Locator 
Reld 30413. When so interpreted. Pointer Locator Raid 30413 contains a signed Integer, which, when 
multiplied by 1 28, gh^es the displacement of a pointer from the ABP specified in ABP Reld 30429. The value 
of this pointer Is then the base to which the dic^acem^ Is added. 

4D Base R.eld 304K is interpreted as having Base is a Name Format 30432 when Base Is a Name Rag 

30413 is set to 1. In Base is a Name Format 30432, Base Field 304^ contains a Name, tf Base Indirect Rag 
30415 Is not set the Name is resoh^d to obtain the Base. If Base Indirect Rag 30415 is set the name is 
evaluated to obtain a pointer value, and that pointer value Is the Base. 

4S a Archftectural Bftse Pointers (Figs. 305, 306) 

If Base is a Name Rag 30413 belonging to a NTE 30401 is not set Base Reld ^25 specifies one of the 
three ABPs In C5 10110: 

— . PBP specifies a location in Procedure Object 608 to which displacements may be added to obtain the 
locations of Literals and SINs. 
so — SDP specifies a location in a Static Data Block for an invocation of a Procedure 602 to which 
displacements may be added to obtain the locations of static data and linkage pointers to Procedures 
602 contained in other Procedure Objects 608 and static data. 
— FP specifies a location in the MAS frame belonging to Procedure 602*8 current invocation to which 
displacements may be added to obtain the location of local data and linkage pointers to arguments. 
ss Each time a Process 610 invokes a Procedure 602, Call microcode saves the current values of the ABPs 

on Secure Stack 10336, calculates the values of the ABPs for the new invocation, and places the resulting 
Logical Descriptors 27116 in FU 10120 registers, where they are accessible to Namespace microcode. 

Call microcode calculates the ABPs as follows: PBP is obtained directly from PBP Reld 30315 in PED 
30303 belonging to the Procedure 602 being executed All that ts required to make it into a Logical 
60 Descriptor 271 16 is the addition of the AON for Procedure Object 608's UID. 

SDP is obtained by performing a pointer-to-descriptor translation on SDPP Field 30313. FP, finally. Is 
provided by the portion of Call microcode which creates the new i\AAS 502 frame for the invocation. As is 
described in detail in the discussion of Call, the Call microcode copies linkage pointers to the invocation's 
actual arguments onto A/IAS 502, sets FP to point to the location following the last actual argument and 
65 then allocates storage for the invocation's local data. Positive displacements from FP thi« specify locations 
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in the local data, while negative offsets specify linkage pointers, 
a^. Resolving and Evaluating Names (Fig. 305) 
The prinnary operations performed by Namespace are resolving names and evaluating them. A Name 
has been resolved when Namespace has used the ABPs and Information contained in the Name's NTE 
^ 30401 to produce a Logical Descriptor 271 16 for the Name; a name has been evaluated when Namespace 
has resolved the Name, presented the resulting Logical Descriptor 27116 for the Name to memory, and 
obtained the value of the data repr^ented by the Name frorn memory. 

The resolve operation has three parts, which may be performed In any orden 

— Obtaining the Base from Base Reld 30425 of the Name's NTE 30401. 

— Obtaining the displacement 

— Obtaining the length from Length Reld 30435. 

Obtaining the length is the simplest of the operations: if Length in a Name Flag 3041 1 is set the length 
is the value obtained by evaluating the Name contained in Length Reld 30435; otherwise, Length Reld 
30435 contains a Rterat value and the length is that literal's value. 

There are four ways in which the Base may be calculated. Which is used depends on the settings of 
Base is a Name Flag 30413 and Base Indirect Rag 30415: 

— Both Rags 0: the ASP specified in ABP ReW 30429 is the Base. 

— Base is a Name Rag 30413 O and Base Indirect Flag 30415 1 : The Base is the location contained in the 
pointer specified by ABP Reld 30429 and pointer Locator Reld 30431. 

^ - — Base is a Name Flag 30413 1 and Base Indirect Rag 30415 0: The Base is the location obtained by 
resolving tiie Name in Base Field 30425. 

— Both Rags 1: The Base is the location oknained by evaluating the Name In Base Reld 30425. 

The manner in which Namespace calculates the displacement depends on whether NTE ^)401 
represents a scaler data item or an array data item. In the first case, Namespace adds the value contained in 
^ I^placemem Reld 30437 and Displacement Extension Reld 30439 to the location otnained for the Base; in 
the second case. Namespace evaluates index Name Reld 30441 and lES Field 30445, multiplies the 
resulting values together, and adds the product to the value in Displacement Reld 30437 in order to obtain 
the displacement 

If any field of a NTE 30401 contains a Name, Namespace obtains the value or location represented by 
^ the Name by performing a Resolve or Evaluation operation on it as required. As mentioned in the 
discussion of NTEs 30401, flags in Flags Reld 30408 indicate which fields of an NTE 30401 contain Names. 
Since the NTE 30401 for a Name used in another NTE 30401 may itself contain Names. Namespace 
performs the Resolve and Evaluation operations recursively. 

35 b.b. Implementation of Name Evaluation and Name Resohre in CS 10110 

tn the present embodiment the Name Evaluation and Resolve operations are carried out by FU 10120 
microcode Eval and Resolve commands. Both comnoands require two pieces of information: a register in 
the currem frame of SR portion 10362 of GRF 1 0354 for receiving Logical Descriptor 271 1 6 produced by the 
operation, and the source of the Name %vhlch is to be resoNed or evaluated. Both Resolve and Eval may 

49 choose between three sources: Parser 20264, Name Trap 20254, and the tow-order 16 bits of the output 
register for OFFALU 20242. Resolve may specify current frame registers 0« 1, or 2 for Logical Descriptor 
271 16, and Eval may specify current frame registers 0 or 1. At the end of the Resolve operation. Logical 
Descriptor 271 16 for the data represented by the Name Is In the spedfied SR 10362 register and at the end 
of the Evaluation operation. Logical Descriptor 27116 is In the spedfied SR 10362 register and the data's 

^ value has be&\ transferred via MOD Bus 10114 to EU 10122's OPS 20322. 

The execution of both Resoh/e and Eval commands always begin with the presentation of the Name to 
Name Cache 10226. The Name presented to Name Cache 10226 is latched into Name Trap 20254» where it is 
available for subsequent use by Name Resolve microcode. 

If there is an entry for the Name In Name Cache 10226, a name cache hit occurs. For Names with NTEs 

so 30401 fulfiliing three conditions, the Name Cache 10226 entry for the Name is a Logical Descriptor 271 16 for 
the data item represented by the Name. The oorMlitions are the following: 

— NTE 30401 contains no Names. 

— Length Reld of NTE 30401 specifies a length of less than 256 bhs. 

— If Base is litdirect Rag 30415 is set, Pointer Displacement Reld 30431 must have a negative value, 
ss indicating that the base is a linkage pointer. 

Logical Descriptor 271 16 can t>e encached In this case because neither the location nor the length of the 
data represemed by the Name can change during the life of an invocation of Procedure 602 to which the 
Name belongs. If the Name Cache 10226 entry for the Name is a Logical Descriptor 27116, the hit causes 
Name Cache 10226 to place Logical Descriptor 271 16 in the specified SR 10362 register- In all other cases, 

60 the Name Cache 10226 entry for the Name does not contain a Logical Descriptor 27116, and a hit causes 
Name Cache 10226 to emit a JAM signal. The JAM signal invokes microcode which uses Information stored 
in Name Cache 10226 to construct Logical Descriptor 27116 for the data item represented by the Name. 
JAMS are explained in detail below. 

If there is no entry for the Name in Name Cache 10226, a Name Cadie Miss occurs, and Name Cache 

& 10226 emits a cache miss JAM signal. The Name Resolve microroutine Invoked by the cache miss JAM 
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signal constructs an entryr in Name Cache 1 0226 from the Name's NTE 30401, using FU 10120's DESP 20210 
to perfonm the necessary calculations. When it Is finished, the cache miss microcode leaves a Logical 
Descriptor 27116 for the Nanne in the specified SR 10362 register and returns- 

The Resolve operation is over when Logical Descriptor 27116 has been placed in the specified GRF 
^ 10354 register; the Evaluation operation continues by presenting Logical Descriptor 27116 to Memory 
Reference Unit 27017, which reads the data represented by Logical Descriptor 27116 from nfiemory and 
places it on OPB 20322. The memory reference may result In Protection Cache 10234 misses and ATU 10228 
misses, as well as protection faults and page faults, but these are handled by nneans of event signals and 
are therefore Invisible to the Evaluation operation. 

Name Cache 1 0226 produces 15 different JAIW signals. The signal produced by a JAM depends on the 
following: whether the operation Is a Resolve or an Eval, which register Logical Descriptor 27116 Is to be 
placed in, whether a miss occurred, and in the case of a hit, which register in the Name Cache 10226 entry 
for the Name was loaded last From the point of view of the behavior of the microcode invoked by the JAM, 
the last two factors are the most important Their relation to the microcode is explained in detail below. 

In the present enr^bodlment, all entries in Name Cache 10226 are invalidated when a Procedure 602 
calls another Procedure 602* The Invalidation is required because Calls always change the value of FP and 
may also change the values of SDP and PBP, thereby changing the meaning of NTEs 30401 using 
displacements from ABPs. Entries for Names in invoked Procedure 602 are created and loaded into Name 
Cache 10226 when the Names are evaluated or resolved and a cache miss occurs. 
^ The following discussion will first present Name Cache 10226 as it appears to the microprog rammer 
and then explain in detail how Name Cache 10226 Is used to evaluate and resolve Names, how It is load^, 
and how It is flushed. 

cc Name Cache 10226 Entries {Rg. 306) 

^ The structure and the physfcal behavior of Name Cache 10226 was presented In the discussion of FU 
10120 hardware; here, the logical stnicture of Name Cache 10226 entries as they appear to the 
. microprogrammer Is presented. To the microprogrammer. Name Cache 10226 appears as a device which, 
when presented a Name on NAME Bus 20224, .ah^vays provides the microprogrammer with a Name Cache 
10226 entry for the Name consisting of four registers. The microprogrammer may read from or write to any 

» one of the four registers. When the microprogrammer writes to the four registers^ the action taken by Name 
Cadie 10226 when a hit occurs on the Name assodated with the four registers depends on which of the 
registers has most reoentiy been loaded. The means by which Name Cache 10226 associates a Name with 
the four registers, and the means by which Name Cache 10226 provides registers when it is full are invisible 
to the microprogrammer. 

3S Rg. 308 Illustrates Name Cache Entry 30601 for a Name. The four Registers 30602 in Name Cache Entry 
30601 are numbmd 0 through 3, and each Register 30602 has an AON, offset and length field like those In 
GBF taaSA registers, except that some flag bits In GRF 103S4 register AON fields are not included in 
Register 30602 fields, and the length field in Register 30602 is 8 bits long. As is the case with GRF 10354 
registers, the microprogrammer can read or write individual fields of Register 30602 or entire Register 

^ 300)2. Name Cache Entry 30601 Is connected via DB 27021 to DESP 20210. and consequently, the contents 
of a GRF 10354 register may be obtained from or transferred to a Register 30602 or viceversa. When the 
contents of a Register 30602 have been transfered to a GRF 10354 register, the contents may be processed 
using OFFALU 20242 and other arithnnetic-logtcal devices In DESP 20210. 

« d.d. Name Cache 10226 Hits 

When a Name Is presented to Name Cache 10226 and Name Cache 10226 has a Name Cache Entry 

30601 containing information about the Name, a name cache hit occurs. On a hit. Name Cache 10226 
hardware afwdr/s loads the contents of Register 30602 0 of the Name's Name Cache Entry 30601 into the 
GRF 10354 register specified in the Resoh^e or Eval microcommand. In addition, a hit may result in the 

60 Invocation of microcode via a JAiVI: 

— The JAiVI may invoke special microcode for resolving Names of array elements whose NTEs 30401 

allow certain hardware accelerations of index calculations. 
~- The JAM may invoke general name resolution microcode which produces a Logical Descriptor 27116 
from the contents of Name Cache Entry 30601. 
55 Whether the hit produces a JAM, and the kind of JAM it produces, are determined by the last Register 

30602 to be loaded when Name Cache Entry 30601 was created by Name Cache Miss microcode. If Register 
30602 0 was the last to be loaded, no JAM occurs; if Register 30602 1 was loaded last, the JAM for special 
array Name resolution occurs; If Register 30602 2 or 3 was loaded last, the JAM for general Name 
resolution occurs. 

60 As may be inferred from the above. Name Cache 10226 hardware defines the manner in which Name 

Cache Entries 30601 are loaded for the first two cases. In the first case, Name Cache Register 30602 0 must 
contain Logical Descriptor 271 16 for the Name's data. As already mentioned, the Name's NTE 30401 must 
therefore describe data whose location and length does not change during an Invocation and whose length 
is less than 256 bits. Name Cache 10226 hardware also determines the form of Name Cache Entries 30601 

ss for encachable an-ays. An encachable array NTE 30401 Is an array NTE 30401 which fills the following 
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conditions: 

— The only Name contained m array NTE 30401 is in Index Name Field 30441. 

— NTE 30401 for the Index Name fills the conditions for scaler NTEs 30401 for which Logical Descriptors 
27116 may be encached. 

s _ The value in lES Reld 30445 is no greater than 128 and a power of 2. 

— Array NTE 30401 othenMse fills the conditions for scaler NTEs 30401 for which Logical Descriptors 
27116 may be encached. 

In the present embodiment the encachable array entry uses registers d 1, and 2 of Name Cache Entry 
30801 for the name: 



Register Contents 

. AON " . OFFSET LENGTH 

fs . 

0 Logical Descriptor 27116 for the index Name 

1 0 lES power of 2 unused 
20 2 Logical Descriptor 271 16 for the array 



When a hit for this type of entry occurs, the resulting JAM signal does two things: rt invokes 
encachable array resolve microcode and it causes the index Name's Logical Descriptor 27116 to be 

2ff presented to Memory Reference Unit 27017 for a read operation which returns the value of the data 
represented by the Index Name to an accumulator in OFFALU 20242. The encachable array resolve 
microroutine then uses the Name that caused the JAM, latched into Name Trap 20^, to locate Register 
30«)2 2 of Name Cache Entry 30601 for the Name, writes the contents of Register 30602 2 into the GRF 
register specified by the Resolve or Eval microcommand, obtains the product of the ES value and the index 

30 value by shifting the index value left the number of times spedfied by the lES exponent in Register 30602 1, 
adds the result to the offset field of the GRF 1 0^ register containing the array's Logical Descriptor 27116, 
thus obtainir^ Logical Descriptor 27116 for the desired array element, and returns. 

For the other cases, the manner in which Name Cache Entries 30601 are loaded and prucessed to 
obtain Logical Descriptore 271 16 Is determined by the microprog rammer. The JAM signal which results if a 

3S Name Cache Entry 30601 is neither a Logical Descriptor 27116 nor an encachable array entry merely 
invokes a microroutine. The microroutine uses the Name latched into Name Trap 20254 to locate the 
Name's Name Cache Entry 30601 and then reads tag values in Name Cache Entry 30601 to determine how 
the information in Name Cache Entry 30601 is to be translated Into a Logical Descriptor 271 16. The contents 
of Name Cache Entries 30601 for the other cases have two general fomis: one for NTEs 30401 with Base is 

40 Indirect Flag ^15 set and one for NTEs In which it is not set The first general form looks like this: 

Register Contents 



45 





AON 




LENGTH 


0 


ABPAON 


tag/length 


untied 


1 


0 


Index name/IES 


unused 


2 


0 


unused 


unused 


3 


0 


data displacement 
from loc. specified 
by pointer 


unused 



Register 30602 0 contains the AON of the ABP. Register 30602 O's offset field contains two items: the 
tag, which contains Rags Held 30408 of NTE 30401 along whh other information, and which determines 
how Name Resolve microcode interprets the contents of Name Cache Entry 30601 , and a value or Name for 
the length of the data Item. Register 30602 1 is used only if the Name represents a data item in an array. It 
then contains the Name from Index Reld 30441 and the Name or value from lES Field 30445. The offset field 
of Register 30^ 3 contains the sum of the offset indicated by NTE 3040r3 ABP and of the displacement 
indicated by NTE 30401. 

The second format used for NTEs 30401 whose bases are obtained from pointers or by resohring a 
ss Name, looks like this: 
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Registers Contents 







AON 


OFFSET 


LENGTH 


s" 


0 


0 


tag/length 


unused 




1 


0 


index name/IES 


unused 


70 


2 


0 


FM and type bits/ 
base field 


unused 




3 


0 


, data displacement 
from ioc. specified 
by pointer or name 


unused 



In this form, the location of the Base must be obtained either by evaluating a pointer or resolving a 
Name. Hence, tfiere is no field specifying the Base's AON. Otherwise, Registers 30602 0 and 1 have the 
20 same contents as in the previous format, in Register 30602 2, the offset field contains Name Table Entry 
3040rs FM Field 30421 and Type Reld 30423 and Base Field 30425. The Offset Field of Register 30G02 2 
contains the value of Name Table Entry 30401 Displacement Fields 30437 and 30439. 

As in Name Table Entries 30401, the Index must be represented by a Name, and length, lES, and Base 
may be represented by Names. If a field of Name Cache Entry 30601 contains a Name, a flag in the tag 
25 indicates that fact, and Name Resolve microcode performs an Eval or Resolve operation on It as required to 
obtain the value or location represented by the name. 

The miciocode which resoK/es Name Cache Entries 30601 of the types just described uses the general 
algorithms described in the discussion of Name Table Entries 30401 . and Is therefore not discussed further 
here, 

30 

e. e. Name Cache 10226 Misses 

When a Name is presented to Name Cache 10226 and there Is no Name Cache Entry 30601 for the 
Name, a name cadte miss occurs. On a miss Name Cache 10226 hardware emits a JAM signal which 
invokes name cache miss microcode. The microcode obtains the Name which caused the miss from Name 

X Trap 202S4 and locates the Name's NTE 30401 by adding the Name to the value of NTP 30311 from PBD 
30303 for Procedure 602 being executed. As will be explained In detail later, when a Procedure 602 is called, 
the Call microcode plac» the AON and offset specifying the NTP's location in a register in GR's 10360. 
Using the information contained in the Name's NTE 30401, the Cache Miss microcode resoK^ the Name 
and constructs a Name Cache Entry 30601 for It As described above, the microcode detemnlnes the method 

40 by which rt resolves the Name and the form of the Name's Name Cache Entry 30601 by reading Rags Field 
30408 in the Name's NTE 30401. Since the descriptions of the Resoh^ operation, the micromachine, Name 
Cache 10226, and the formats of Name Cache Entries 30601 are sufficient to allow those skilled in the art to 
understand the operations performed by Cache Miss microcode, nofur^er description of the microcode is 
provided. 

45 

f. f. Rushing Name Cache 10226 

As described in the discussion of Name Cache 10226 hardware, hardware means, namely VALS 24068, 
exist which allow Name Cache Entries 30601 to be invalidated. Name Cache Entries 30601 may be 
invalidated singly, or alt entries in Name Cache 10226 may be invalidated by means of a single 

$0 microcommand. The latter operation is termed name cache flushing. In the present embocfiment. Name 
Cache 1 0226 must be flushed when Process 61 0 whose Virtual Processor 61 2 is bound to JP 1 01 14 executes 
a Call or a Return and whenever Virtual Processor 612 NO is unbound from JP 10114. Flushing Is required 
on Call and Return because Calls and Returns change the values of the ABPs and other pointers needed to 
resolve Names. At a minimum, a Call produces a new MAS Frame 10412, and a Retum returns to a previous 

55 Frame 10412, thereby changing the value of FP. If the called Procedure 602 has a different PED 30303 from 
that of the calling Procedure 602, the Call or Retum may also change PBP, SDP, and NTP. Rushing Is 
required when a Virtual Processor 612 is unbound from JP 101 14 because Virtual Processor 612 which is 
next bound to JP 10114 is bound to a different Process 610, and therefore cannot use any Information 
belonging to Process 610 bound to the Previous Virtual Processor 612. 

60 

g. g. Fetching the l-Stream 

As explained In the discussion of FU 10120 hardware, SINs are fetched from memory by Prefetcher 
20260. PREF 20260 contains a Logical Descriptor 271 1 6 for a location in Code 1 0344 belonging to Procedure 
602 vtfhich Is cunrently being executed. On any MO cycle, PREF 20260 can place Logical Descriptor 271 16 on 
es DB 27021, cause Memory Reference Unit 27017 to fetch 32 bits at the location specified by Logical 
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Descriptor 27116, and write them into INSTB 20262. When INSTB 20262 is full, PREF 20260 stops fetching 
SINs until Namespace parsing operations, described below, have processed part of the contents of INSTB 
20262, thereby creating space for moro SINs. 

The fetching operation is automatic, and requires intervention from Namespace only when 3 SIN 

5 causes a branch, i.e., cau^ the next SIN to be executed to be some other SIN than the one immediately 
follovnng the current SIN. On a branch. Namespace must load PREF 20260 with the location of the next SIN 
to be executed and cause Pf^EF 20260 to begin fetching SINs at that location. The operation which does this 
Is specified by the load-prefetch-for-branch microcommand. The mlcrocommand specifies a source for a 
Logical Descriptor 27116 and transfers that Logical Descriptor 27116 via DB 27021 to PREF 20260. After 

to PREF 20260 has thus been loaded, it begins fetching SINs at the specified location. Since any SINs still in 
INSTB 20262 have been rendered meaningless by the branch operation, the first SINs loaded Into INSTB 
20262 are simply written over INSTB 20262's prior contents. Fig, 274 contains an example of the use of the 
load-prefetch-for-branch mlcrocommand. 

IS h.h. Parsing the l^ream 

The l-stream as fetched from MEM 10112 and stored in INSTB 20262 Is a sequence of SOPs and Nan^. 
As already mentioned, the Mream has a foced format: in the present embodiment, SOPs are always 8 bits 
long, and Names may be 8, 12^ or 16 bits long. The length of Names used in a given procedure Is fixed, and 
is indicated by the value in K Field 30305 in the Procedure 602's PED 30303. The Namespace parsing 

20 operations obtain the SOPs and Names from the l-stream and place them on NAME Bus 20224. The SOPs 
are transferred via this bus to the devices in SOP Decoder 27003, while the Names are transferred to Name 
Trap 20254 and Name Cache 10226 for Resolve and Evaluation operations as described above. As ti^e 
parsing operations obtain SOPs and Names, they also update the three program counters CPC 20270, EPC 
20274, and IPC 20272. The values in these three counters are offsets from PBP which point to locations in 

25 Code 10344 belonging to Procedure 602 being executed. CPC 20270 points to the l-stream syllable cunrently 
being parsed, so it is updated on every parsing operation. &C 20274 points to the beginning of the last SIN 
executed by JP 101 14, and IPC 20272 points to the beginning of the current SIN, so these program counters 
are changed only at the beginning of the execution of an SIN, i.e., when a SOP is parsed. 

As described in the discussion of RJ 10120 hardware, in the current implementatiotw parsing consists 

30 physically of reading 8 or 16 bits of data from a location in INSTB 20262 identified by a pointer for INSTB 
20262 which is accessible only to the hardware. As data fe read, the hardware incrments the pointer by the 
numtser of tnts read, wrapping around and returning to tiie beginning of INSTB 20262 if It reaches the end. 
At the same time that the hardware increments the pointer, ft Irorements CPC 20270 by the same number of 
bits. As previously mentioned, CPC 20270 contains the offset from PBP of the SOP or Name b^ng currentiy 

35 par^, thus coordinating the reading of INSTB 20262 with the reading of Procedure COS'S Code 10344. 

The number of bits read depemte on whether Parser 20264 is reading an SOP or a Name, end in the 
latter case, by the syllable size spedfied for the Name. The syllable size is contained in CSSR 24112. On a 
Call to a Procedure 602 which has a different PEO 30303 from tfiat of the calling procedure, the Call 
microcode loads tiie value contained in K Reld 30305 into CSSR 241 12. 

40 Namespace's parsing operations are performed by separate microcommands for parsing SOPs and 

Names. There is a single microcommand for parar>g S-operations: parse-op-stage. The microcommand 
obtains the next eight bits from INSTB 20262, places the bits onto NAME Bus 20224, and latches them into 
LOPCODE Register 24212. It also updates EPC 20274 and IPC 20272 as required at the beginning of an SIN: 
EPC 20274 IS set to IPC 20272's former value, and IPC 20272 is set to CPC 20270's value. At the end of the 

MS operation, CPC 20270 is incremented by 8. Since the parsing of an SOP always occurs as the first operation 
in the interpretation of an SIN, the parse-op-stage command Is generally combined with a dispatch fetc^ 
command. As will be explained below, the latter command interprets the S-operation as an address in 
FDISP 24218, and FDISP 24218 in turn produces an address In FUSITT 11012, The latter address is the 
location of the beginning of the SIN microcode for the SIN. 

so 

There are two microcommands for parsing Names: 
parse_kJoad_epc and parse_k.dispatch_ebox. Both commands obtain a number of bits from INSTB 20262 
and place them on NAME Bus 20214. With both microcommands, the syllable size, K, stored in CSSR 241 1 2, 
determines the number of bits otrtained from INSTB 20262. Both commands also increment CPC by the 
55 value stored in CSSR 24112. in addition, parse_kJoad_epc sets EPC to IPCs value, while 
parse.Mispatch^ebox also dispatches EU 10122, i.e., interprets the SOP saved in LOPCODE 24210 as an 
address in EDISP 24222, which in turn contains an address in EU EUSITT 20344. The EU EUSITT 20344 
address is passed via EUDIS Bus 20206 to COMQ 20342 in EU 10122. 

so c. The S-lnterpreters (Rg. 307) 

CS 10110 does not assign fixed meanings to SOPs. While all SOPs are 8 bits long, a ghren 8 bit SOP 
may have one meaning in one S-Language and a completely different meaning in another S-Language. The 
semantics of an S-Language's S-operations are determined completely by the S-interpreter for the S- 
Language. Thus, in order to correctly interpret an S-operation, CS 101 10 must know what S-interpreter it Is 

es to use. The S-interpreter is identified by a UID pointer with offiset 0 in SIP Reld 30309 of PED 30303 for 
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Procedure 602 that CS 10110 is currently executing. In the present embodiment, the UID is the UID of a 
microcode object which contains FU 10120 microcode. When loaded into FUSITT 11012, the microcode 
interprets SOPs as defined by the S-Language to which the SOP belongs. In other embodiments, the UID 
may be the UID of a Procedure Object 608 containing Procedures 602 which interpret the S-Language's 
" ^ SOPs, and In still others, the S-lnterpreter may be contained in a PROM and the S-interpreter UID may not 
specif an object, but may serve solely to identify the Snnterpreter. , ^ « „ 

When a Procedure 602 executes an SIN on JP 10114, CS 10110 must translate the value of SIP Pointer 
30309 for Procedure 602 and the S-lnstmction's SOP Into a location in the microcode or high-level language 
code which makes up the S-interpreter. The location obtained by the translation is the beginning of the 
microcode or high-level language code which implements the SIN. The translation of an SOP together v\rfth 
SIP Pointer 30309 Into a location in the S-interpreter is termed dispatching. Dispatching In the present 
embodiment cnvoKm two primary components: a table Jn memory which translates the value of SIP 
Pointer 30309 into a small integer called the Ofalecl Number, and S-operation Decoder Portion 27003 of the 
FU 10120 micromachine. The following discussion will first present the table and explain how an SIP 
Pointer 30309 is translated Into a Dialect Number, and then explain how the Dialect Number and the SOP 
together are translated into locations in FUSfTT 11012 and EUSITT 20344. 

1. Translating SIP Into a Dialect Number (Fig. 307) 

In the present embodiment, all S-lnterpreters in CS 101 10 are loaded into FUSITT 11012 when CS 101 10 
begins operation and each S-interpreter is always placed in the same location. Which S-interpreter is used 
to interpret an S-Language is determined by a value stored in dialect register RD1AL 24212, Consequently, 
in the present embodiment a Call to a Procedure 602 whose S-interpreter differs from that of the calling 
Procedure 602 must translate the UID pointer contained In SIP Reld 30309 into a Dialect Number. 

Fig. 307 represents the table and microcode which performs this translation in the present 
^ embodiment. S-interpreter Translation Table {SID 30701 Is a table which is indexed by small AONs. Each 
STT Entry (STTE) 30703 has two fields: an AON Field 30705 and a Dialect Number Reld 307(». Dialect 
Number Reld 30709 contains the Dialect Number for the S-interpreter object whose AON is in AON Reld 
30705. 

When CS 101 10 t>egins operation, each S-lnterpreter object Is wired active and assigned an AON small 
^ enough to serve as an index in STT 30701. By convention, a given S-interpreter objec t is al ways assigned 
the same AON and the same Dialect Number. The AON is placed in AON Field 30705 of SHE 30703 indexed 
by the AON, and the Dialect Number is placed In Dialect Number Reld 30709. Since the S-iirterpreter 
objects are wired active, these AONs will never be reassigned to other objects. 

On a Call which requires a new S-interpreter, Call microcode c^talns the new SIP from SIP Reld 3 03(», 
^ calls KOS LAR microcode to translate its UID to its AON, uses the AON to locate the S-lnterpreter's STTE 
30703, and places the value of Dialect Number Reld 30709 into RDIAL 21242. 

Other embodiments may allow S-lnterpreters to be loaded into FUSITT 11012 at times other than 
system initialization, and allow S-interpreters to occupy different locations in FUSITT 11012 at different 
times. In these embodiments, STT 30701 may be implemented in a manner simitar to the implementations 
^ of AST 10914 or MHT 10716 in the present embodiment 

2. Dispatching ^ 

Dispatching Is accomplished by Dispatch Rles 27004. These files translate the values provided by 
RDIAt 24212 and the SOP of the S^nstruction lieing executed Into the location of microcode for the SIN 
specified by the S-operation in the S-interpreter specified by the value of RDIAL 24212. The present 
embodiment has tiiree dispatch files: FDISP 24218, FALG 24220, and EDISP 24222. FDISP 24218 and FALG 
24220 translate S-operations into locations of microcode which executes on FU 10120; EDISP 24222 
translates S-operatioris into locations of microcode which executes on EU 10122. The difference between 
FDISP 24218 and FALG 24220 Is one of speed: FDISP 24218 can translate an SOP in the same 

SO microinstruction which performs a parse.op^stage command to load the SOP into LOPCODE 24210, FALG 
24220 must perfomfi the translation on a cycle following the one in which the SOP is loaded into LOPCODE 
24210. Typically, the location of the first portion of the microcode to execute an S-operation is contained in 
an FDISP 24218 register, the location of portions executed later is contained in an FALG 24220 register, and 
the location of microcode for the S-operation which executes on EU 10122 is contained in EDISP 24222. 

ss In the present embodiment, the registers accomplish the translation from S-operation to microcode 

location as follows: As mentioned in the discussion of FU 1 0120 hardware, each Dispatch File contains 1024 
registers. Eadi register may contain an address In an S-lnterpreter, As will be seen in detail later, the 
address may be an address in an S-intcrpreter's object, or it may be the address in FUSITT 1 101 2 or EUSITT 
20344 of a copy of microcode stored at an S-interpreter address. The registers in the Dispatch Files may be 

so divided into sets of 128 or 256 registers. Each set of registers translates the SOPs for a single S-Language 
Into locations in microcode. Which set of registers is used to Interpret a given S-operation is decided by the 
value of RDIAL 24212; which register in the set is used Is determined by the value of the S-operation. The 
value contained in the specified register is then the location of microcode which executes the S-instruction 
specified by the S-operation In the S-Language specified by RDIAL 24212. 

fiff Logically, the register addressed by the concatenated value in turn contains a 1 5 bit address which Is 
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the location in the S-interpreter of the first mfcroinstruction of microcode used to execute the S-fnstniction 
specified by the S-operation in the S-Language specified by the contents of RDIAL 2421Z In the present 
embodiment the microcode referred to by the address may have been loaded into FUSITT 11012 and 
EUSITT 20344 or it may be available only in memory. Addresses of microcode located in FUSITT 1 1012 and 

s EUSITT 20344 are only eight bits long. Consequently, if a Dispatch RIe 27004 contains an address which 
requires more bits than that, the microcode specified by the address is in memoiy. As described in the 
discussion of FU 10112 hardware, addresses larger than 8 k^ts produce an Event Signal, and microcode 
invoked by tt»€ event signal fetches the microinstruction at the specified address in the S-lnterpreter from 
memory and loads it into location 0 of FUSITT 11012. The event microcode then returns, and the 
microinstruction at location 0 is executed. If the next microinstruction also has an address larger than 8 bits, 
the event signal occurs again arxJ the process described above is repeated. 

As previously mentioned, FDISP 24218 is faster than FALG 24220. The reason for the difference in 
speed is that FDISP registers contain only 6 bits for addressing the S-interpreter. The present embodiment 
assumes that all microcode addrereed via FDISP 24218 is contained in FUSITT 1 101 2. It concatenate 2 zero 
bits with the sbc bits in the FDISP 24218 register to produce an B bit address for FUSITT 1 1 012. FDISP 24218 
registers can thus contain the location of every fourth FUSITT 11 012 register between FUSITT register 25& 
and FUSITT register 448. The microcode loaded into these locations in FUSITT 11012 is microcode for 
operations which are performed at the start of the SIN by many different SINs. For example, all SINs which 
perform operations on 2 operands and assign the result to a location specified by a third operand must 

20 parse and evaluate the first two operands and parse and resoh^e the third operand. Only after these 
operations are done are SINs-spectfic operations performed. In the present embodiment, the microcode 
which parses, resolves, and evaluates the operands is contained in a part of FUSITT 11012 which is 
addressable by FDISP 24218. 

As previously mentioned, in the present embodiment, FUSITT 1 1012 and EUSITT 20344 may be loaded 

^ only when CS 101 10 is initialiaed. The microcode loaded into FUSITT 1 1012 and EUSITT 20344 is produced 
by the microbinder from the microcode for the various SINs. To achieve efficient use of FUSITT 11012 and 
EUSnr 20344, microcode for operations shared by various S-interpreters appears only once in FUSITT 
11012 and EUSITT 20344. While the SINs in dtfferem S-Languages which share the microcode have 
different registers in FDISP 24218, FALG 24220, or EDISP 24222 as the case may be, the registers for each of 

50 the S^nstructfons contain the same location in FUSITT 1 1012 or EUSITT 20344^ 

4. The Kernel Operating System 
A. Introduction 

Many of the unique properties of CS 10110 are produced by the manipulation of tables in MEM 10112 
^ and Secondary Storage 10124 by programs executing on JP 101 14. These programs and tables together 
make up the Kernel Opera^ng System (KOS). Having described CS 101 ID'S components and the meat^ by 
which they cooperate to execute computer programs, this specification now presents a detailed account of 
KOS and of the propeitles of 08 1 01 1 0 which h produces. The discussion begi ns with a general introduction 
to operating systems, then presents an overview of CS 10110*8 operating systems, an overview of the KOS, 
40 and detailed discussions of the implementation of objects, access control, and Processes 610. 

a. Operating Systems (Fig. 401) 

in CS 10110, as In other computer systems, the operating system has two functions: 

— it controls the use of CS 10110 resources such as JP 10114, MEM 10112, and devices In lOS 10116 by 
4^ programs being executed on CS lOlia 

— It defines how CS 10110 resources appear to users of CS 10110. 

The second function Is a consequence of the first: By controlling the manner in which executing 
programs use system resources, the operating system in fact determines how the system appears to its 
users. Rgure 401 is a schematic representation of the relationship between User 40101, Operating System 
50 40102, and System Resources 4010a When User 40101 wishes to use a System Resource 40103, User 

40101 requests the use of System Resource 40103 from Operating System 40102, and Operating System 

40102 in turn commands CS 10110 to provide the requested Resources 40103. For example, when a user 
program wishes to use a peripheral device, ft does not deal with the device directly, but instead c^ls the 
Operating System 40102 procedure 602 that controls the device. While Operating System 40102 must take 

55 into account the device's complicated physical properties, the user program that requested the device need 
know nothing about the phyacal properties, but must only know what information the Operating System 
40102 Procedure 602 requires to perform the operation requested by the user program. For example, while 
the peripheral device may require that a precise pattern of data be presented to h, the Operating System 
40102 procedure 602 may only require the data itself from the user program, and may format the data as 

60 required by the peripheral device. The Operating System 40102 Procedure 602 that controls the peripheral 
device thus transforms a complicated physical interface to the device into a much simpler logical interface. 

1. Resource Controlled by Operating Systems (Fig. 402) 

Operating Systems 401 02 control two kinds of resources: physical resources and virtual' resources. The 
65 physical resources in the present embodiment of CS 10110 are JP 10114, lOS 10116 and the peripheral 
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devices associated with lOS 10116, MEM 10112, and Secondary Storage 10124, Virtual resources are 
resources that the operating system ilaelf defines for users of CS 10110. As was explained above, in 
controlling how CS 10110's resources are used. Operating System 40102 defines how CS 10110 appears to 
the users. Instead of the physical resources controlled by Operating System 40102, the user sees a far 

s simpler set of virtual resources. The logical 1/0 device interface that Operating System 40102 gives the user 
of a physical 1/0 device is such a virtual resource. Often, an Operating System 40102 will define sets of 
virtual resources and multiplex the physical resources. among these virtual resources. For instance. 
Operating System 40102 may define a set of Virtual Processors 612 that correspond to a smaller group of 
physical processors, and a set of virtual memories that correspond to a smaller group of physical 

fO resources. When a user executes a program, It runs on a Virtual Processor 612 and uses virtual memory. It 
seems to the user of the virtual processor and the virtual memory that he has sole access to a physical 
processor and physical memory, but in fact, Operating System 40102 is niultiplexing the physical 
processors and memories among the Virtual Processors 612 and virtual memories. 

Operating System 40102, too, uses virtual resources. For Instance, the memory management portion 

IS of an Operating System 40102 may use I/O devices; when It does so, it uses the virtual I/O devices defined 
by the portion of the Operating System 40102 that manages the IfO devices. One part of Operating System 
40102 may also redefine virtoial resources defined by other parts of Operating System 40102. For instance, 
one part of Operating System 40102 may define a set of primitive virtual I/O devices and another part may 
use these primitive virtual I/O devices to define a set of high-level user-oriented I/O devices. Operating 

20 System 40102 thus turns the physical CS 10110 into a hierarchy of virtual resources. How a user of CS 
10110 percehres CS 10110 depends entirely on the level at which he is dealing with the virtual resources. 

The entity that uses the resources defined by Operating System 40102 Is the process. A Process 610 
may be denned as the activity resulting from the execution of a program with its data by a sequential 
processor. Whenever a user requests the execution of a program on CS 10110, Operating System 40102 

25 creates a Process 610 which then executes the Procedures 602 making up the user's program. In physical 
terms, a process 610 is a set of data bases in memory that contain the current state of the program 
execution that the process represents. Operating System 401 02 causes Process 610 to execute the program 
by giving Process 610 access to the virtual resources which it requires to execute the program, by giving 
the virtual resources access to those parts of Process 610*8 state which they require to perform their 

30 operations, and by giving these virtual resources access to the physical resources. The temporary 
relationship of one resource to another or of a Process 610 to a resource is called a binding. When a Process 
610 has access to a given Virtual Processor 612 and Virtual processor 612 has access to process 610*5 state, 
proc^ 61 0 is bound to Virtual Processor 612, and when Virtual Processor 612 has access to JP 101 14 and 
Virtual Processor 612's state is loaded into JP 10114 registers. Virtual processor 612 is bound to JP 10114, 

35 and JP 10114 can execute SINs contained in Procedures 602 in the program being executed by Process 610 
bound to Virtual Processor 612. Binding and unlrinding may occur many times In the course of the 
execution of a program by a Process 610. For instance. If a Process 510 executes a reference to data and the 
data is not present in MEM 101 12, then Operating System 40102 unUnds Process 610's >«rtual Processor 
612 from JP 10114 until the data is available in MEM 10112. If the date is not available for an extended 

40 period of time, or if the user for whom Process 610 is executing tiie program wishes to stop the execution of 
the program for a while. Operating System 40102 may unbind process 610 from its Virtual Processor 612. 
Virtual Processor 612 Is then available for use by other Processes 610. 

As mentioned above, the binding process involves ghdng a first resource access to a second resource, 
and using the first resource's state in the second resource. To permit binding and unbinding. Operating 

^ System 40102 maintains data bases that contain the cuoent state of each resource and each Process 610. 
State may be defined as the Information that the operating system must have to use the resource or 
execute the Process 61 0. The state of a line printer, for Instance, may be variables that indicate whether the 
line printer is busy, free, off line, or out of order. A Process 610's state is more involved, since it must 
contain enough information to allow Operating System 40102 to bind Process 610 to a Virtual Processor 

so 61 2, execute Process 61 0 for a while, unbind Process 61 0, and then rebind it and continue execution where 
It was halted. A process 610's state thus Includes alt of the data used by Process 610 up to the time that it 
was unbound from a Virtual Processor 612, along with information indicating whether Process 610 is ready 
to begin executing again. 

Figure 402 shows the relationship between Processes 610, virtual, and physical resources in an 

55 operating system. The figure shows a multi-process Operating System 40102, that is, one tiiat can 
multiplex CS 10110 resourt^s among several Processes 610. The Processes 610 thus appear to be 
executing concurrentiy. The solid arrows In Rgure 402 indicate bindings between virtual resources or 
between virtual and physical resources. Each Process 610 is created by Operating System 40102 to execute 
a user program. The program consists of Procedures 602, and Process 610 executes Procedures 602 m the 
so order prescribed by the program. Processes 610 are created and managed by a component of Operating 
System 40102 called the Process Manager. Process Manager 40203 executes a Process 610 by binding it to 
a Virtual Processor 612. There may be more Processes 610 than there are Virtual Processors 612. In this 
case. Operating System 40102 multiplexes Virtual Processors 612 among Processes 610. 

Virtual Processors 612 are created and made available by another component of Operating System 
65 40102, Virtual Processor Manager 40205. Virtual Processor Manager 40205 also multiplexes JP 10114 
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among Virtual Processors 612. If a Virtual Processor 612 is ready to run, Virtual Processor Manager 40205 
binds it to JP 101 14. When Virtual Processor 612 can run no longer, or when another Virtual Processor 612 
requires JP 10114, Virtual Processor Manager 40205 unbinds running Virtual Processor 612 from JP 101 14 
and binds another Virtual Processor 612 to it 
^ Virtual Processois 612 use virtual mennory and I/O resources to perform memory access and input- 

output Virtual Memory 40206 is created and managed by Virtual Memory Manager 40207, and Virtual I/O 
Devices 40208 are created and managed by Virtual I/O Manager 40209. Like Virtual Processor Manager 
40205, Components 40207 and 40209 of Operating System 40102 multiplex physical resources among the 
virtual resources. As described above, one set of virtual resources may use another set One way in which 
this can happen is Indicated by the broken anrows in Rgure 402. These arrows show a binding between 
Virtual Memory and Virtual \fO Device 40208. This binding occurs when Virtual Memory 40206 must 
handle a reference to data contained on a peripheral device such as a disk drive. To the user of Virtual 
Memory 40206« all data appears to be available In MEM 10110. In fact however, the data Is stored on 
peripheral devices such as disk drives, and copied into MEM 10112 when required. When a Process 610 
references data that has not been copied Into MEM 101 12, Virtual Memory 40206 must use lOS 10116 to 
copy the data into MEM 10112. In order to do this, it uses a Virtual I/O Device 40208 provided by Virtual I/O 
Manager 40209. 

20 b. The Operating System In CS 101 10 

For the sake of clarity. Operating System 40102 has been de^ribed as though it existed outside of CS 
10110. In fact however. Operating System 40102 Itself uses the resources it controls. In the present 
embodiment parts of Operating System 40102 are embodied in JP 10114 hardware devices, parts are 
embodied In microcode which executes on JP 10114, and parts are embodied In Procedures 602. These 

25 Procedures 602 are sometimes called by Processes 610 acecuting user programs, and sometimes by 
special Opereting System Processes 610 which do nothing but execute operations for Operating System 
40102. 

The manner in which the components of Operating System 40102 interact may be Illustrated by the 
way in which CS 101 10 handles a page feult i.e., a reference to data which is not available in MEM 101 10. 

30 The first indication that there may be a page fault is an ATU Miss Event Signal. This Event Signal is 
g^erated by ATU 10228 in FU 10120 when there Is no entry in ATU 10228 for a Logical Descriptor 27116 
used in a read or write operation. The Event Signal invokes Operating System 40102 microoodst which 
examines a table in MEM 10112 in order to find whether the data described by Logical Descriptor 27116 has 
a copy in MEM 10112. If the table indicates that there is no copy. Operating System 40102 microcode 

35 communicates the fact of the page fault to an Operating System 40102 Virtual Memory Manager process 
61 0 and removes Virtual Processor 612 bound to the Process 61 0 whteh was executing when the page fault 
occurred from JP 10114. Some time later. Virtual Memory Manager Process 610 Is bound to JP 10114. 
Procedures ^2 executed by Virtual Memory Manager Process 610 then initiate the I/O operations required 
to locate the desired data in Secondary Storage 10124 and copy it into MEM 10112. When the data is 

40 available In MEM 101 12, Operating System 40102 allows Virtual Processor 612 bound to Process 610 which 
was executing when the page fault occurred to return to JP 10114. Virtual Processor 612 repeats the 
memory reference v^ich caused the page fault and since the data Is now in MEM 10112, the reference 
succeeds and execution of Process 610 continues. 

4S 

c. Extended Operating System and the Kernel Operating System (Rg, 403) 

In CS 10110, Operating System 40102 is made up of two component operating systems, the Extended 
Operating System (EOS) and the Kernel Operating System (KOS). The KOS has direct access to the physical 
resources. It defines a set of primitive virtual resources arid multiplexes the physical resources among the 

so primitive virtual resources. The EOS has access to the primith^e virtual resources defirted by KOS, but not to 
the physical resources. The EOS defines a set of user-level virtual resources and multiplexes the primitive 
virtual resources defined by KOS among the user level virtual resources. For example, KOS provides EOS 
with Processes 610 and Virtual processors 612 and binds Virtual Processors 612 to JP 10114, but EOS 
decides when a Process 610 is to be created and when a process 610 is to be bound to a Virtual processor 

©612. 

Rgure 403 shows the relationship betwe^ a user Process 610, EOS, KOS, and the physical resources 
in CS 10110. Rgure 403 shows three levels of interface between executing u^r Process 610 and JP 101 14« 
The highest level of interface is Procedure Level 40302. At this level. Process 610 interacts with CS 101 10 by 
calling Procedures 602 as specified by the program Process 610 is executing. The calls may be either calls 

£0 to User Procedures 40306 or calls to EOS Procedures 40307. When Process 610 is executing a procedure 
602, Process 61 0 produces a stream of SINs. The stream contains two kinds of SINs, S*language SINs 4031 0 
and KOS SINs 40311. Both kinds of SINs Interact with CS 10110 at the next level of interface, SIN-level 
Interface 40309. SINs 40310 and 40311 are interpreted by Microcode 40312 and 40313, and 
Microinstnjctions 40315 interact with CS 10110 at the lowest level of Interface, JP 101 14 interface 40316. As 

CS already explained in the discussion of the RJ 10120 microniachine, certain conditions In JP 101 14 result in 
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Event Signals 40314 which invoke microroutines in S-interpreter Microcode 40312 or KOS Microcode 
40313, Only Procedure-Level Interface 40302 and SIN-level Interface 40309 are visible to users. Procedure- 
level Interface 40309 appears as calls in user Procedures 602 or as statements in user Procedures 602 which 
compilers translate into calls to EOS procedures 602. SIN-level Interface 40309 appears as the Name Tables 
s 10335 and SINs in Procedure Objects 608 generated by compilers. 

A$ Figure 403 indicates, EOS exists only at Procedural Level 40302, while KOS exists at Procedural 
Level 40302, and SIN Level 40304, and vinthin the microcode beneath SIN Level 40309. The only portion of 
the of^rating system that Is directly available to user Processes 610 is EOS Procedures 40307. EOS 
Procedures 40307 may in turn call KOS procedures 40308. In many cases, an EOS Procedure 40307 will 
10 contain nothing more than the call to a KOS Procedure 40308. 

User Procedures 40306, EOS Procedures 40307, and KOS Procedures 40308 all contain S-language 
SINs 40310. In addition, KOS Procedures 40308 only may contain special KOS SINs 40311. Speaal KOS 
SINs 4031 1 control functions that are not available to EOS Procedures 40307 or User Procedures 4(»06, and 
KOS SINs 40311 may therefore not appear in Procedures 40306 or 40307. S-language SINs 40310 are 
w • interpreted by S-interpreter Microcode 40312, while KOS SINs 40311 are Interpreted by KOS Microcode 
40313. KOS Microcode 40313 may also be called by S-interpreter Microcode 40313, Depending on the 
hardware conditions that cause Event Signals 40314, Signals 40314 may cause the execution of either S- 
interpreter Microcode 40312 or KOS Microcode 40313. . . 

Rgure 403 shows the system as it is executing a user Process 610. There are in addition speaal 
^0 Processes 610 reserved for KOS and EOS use. These Processes 610 woric like user Processes 610, but carry 
out operating system functions such as process management and virtual memory management V^^ one 
exception, EOS Processes 61 0 call EOS Procedures 40307 and KOS Procedures 40308, w^ile KOS Proc^ses 
610 call only KOS Procedures 40308. The exception is the beginning of Process 610 execution: KOS 
performs the KOS^evel functions required to begin executing a Process 610 and then calls EOS. EOS 
25 performs the required EOS level functions and then calls the first User Procedure 40306 in the program 
Process 610 is executing. ^ x.._ ^ m 

A descnptlon of how KOS handles page faults can serve to show how the parts of the system at ttie 4P 
10114—, SIN—, and ptooedure Levels vwrfc together, A page fault occurs when a Process 610 references a 
data item that has no copy in MEM 10112. The page fault begins as an Event Signal from ATU 10228. The 
30 Event Signal invokes a microroutine in KOS Microcode 40313. If the microroutlne confifTiis tn^ the 
referenced data item is not in MEM 10112, H records the fact of the page fault In some KOS tables in MEM 
10112 and calls another KOS microroutine that unbinds Virtual Processor 612 bound to Process 610 that 
caused the page fault from JP 10114 and allows another Process 610's Virtual Processor 612 to run. Some 
time after the page fault, a special operating system Process 610, the Virtual Memory ManagerProcess 610, 
ss runs and executes KOS Procedures 403(». Virtual Memory Manager Process 610 initiates the I/O operation 
that reads the data from Secondary Storage 10124 into MEM 1011Z When lOS 10116 has finished the 
operation. Process 610 that caused the pagefautt can run again and Virtual Memory Manager P«>c^ 
performs an operation which causes Process 610's Virtual Processor 612 to again be bound to JP 101 14. 
When Process 610 resumes execution, it again attempts to reference the data. The data is now m MEM 
40 10112 and consequently, the page fault docs not recur. . ^ . 

The division of Operating System 40102 into two hierarchically-related operating systems is 
characteristic for CS 1 01 1 0. Several advantages are gained by such a division: 

— Each of the two operating systenns ts simpler than a single operating system would be. EOS can 
concern itself mainly with resource allocation policy and high-level virtual resource^ while KOS can 

4S concern itself with low-level virtual resources and hardware control. 

— Because each operating system is simpler, it is easier to verify that each system's components are 
performing correctiy, and the two systems are therefore more dependable than a single system. 

— Dividing Operating System 40102 makes It easier to implement different embodiments of CS 10110. 
Only the interface provided by EOS Is visible to the user, and consequentiy, the user interface to the 

so system can be changed without altering KOS. In fact, a single CS 10110 may have a number <rf EOSs. 
and titereby presemdrfferent interfaces to different users. Similarly, changes In the hardware affect the 
implementation of tiie KOS, but not the interface that KOS provides EOS. A given EOS can therefore 
run on more than one embodiment of CS 10110. . . .q ^m aa 

-~ A divided operating system is more secure tiian a single operating system. Physical access to JP 10114 
55 Is provided solely by KOS, and consequentiy, KOS can ensure that users manipulate only those 
resources to vrfiich ttiey have access rights. ^ u i-i^o •„ 

Ail CSs 101 10 will have the virtual resources defined by KOS, while the resources defined by EOS will 
vary from one CS 101 10 to another and even within a single CS 10110. Consequentiy, the remainder of the 
discussion will concern itself with KOS. ^ ^ x t i 

eo The relationship between tiie KOS and the rest of CS 10110 is governed by four prindples: 

— Only the KOS has access to the resources it controls. User calls to EOS may result in EOS calls to KOS, 
and S-language Sli^ may result in invocations of KOS microcode routines, but neither EOS nor user 
programs may directiy manipulate resources controlled by KOS. e- • 

— The KOS is passive. It responds to calls from the EOS, to microcode invocations, and to Event Signals, 
65 but It initiates no action on Its own. 
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— The KOS is invisible to ail system users but the EOS. KOS does not affect the logical behavior of a 
Process 61 0 and is noticeable to users only with regard to the speed with which a Process 610 executes 
on CS 10110. 

As discussed above, KOS manages both physical and virtual resources. The physical resources and 
* some of the virtual resources are viable only within KOS; others of the virtual resources ere provided to 
EOS. Each virtual resource has two main parts: a set of data bases that contain the virtual resource's state, 
and a set of routines that manipulate the virtual resource. The set of routines for a virtual resource are 
termed the resource's manager. The routines may be KOS Procedures 40308^ or they may be KOS 
Microcode 40313. As mentioned, in some cases, KOS uses separate Processes 610 to manage the 
resources. 

For the purposes of this specification, the resources managed by KOS fall into two main groups: those 
associated wth objects, and those associated with. Processes 610. In the following, first those resources 
associated with objects, and then those associated with Processes 610 are discussed. 

B. Objo^ and Object Management (Rg. 404) 

The virtual resources termed objects are defined by KOS and manipulated by EOS and KOS* Objects as 
seen by EOS have five properties: 

— A single UID that Identifies the object throughout the object's life and specifies what Logical Allocation 
Unit (LAU) the object belongs ta 

^ — A set of attributes that describe the object and limit access to it. 

— Bit-addressable contents, I the present embodiment the contents may range from 0 to (2**32) — 1 bits 
in lertgth. Any bit in the contents may be addressed bv* an offeet 

— Objects may be created. 

— Objects may be destroyed. . 

^ All of the data and Procedures 6Q2 tn a CS 101 10 are contained in objects. Any process 610 executing 
on a CS 101 1 0 may use a UID-off set address to attempt to access data or Procedures 602 in certain objects 
on any CS 10110 accesstbie to the CS 10110 on which Process 610 is executing. The objects which n>ay be 
thus accessed by any Process 610 are those having UIDs which are guaranteed unique for all present and 
future CS 10110. Objects with such unique UIDs thus form a single address space which is at least 

30 potentially accessible to any prroess 610 executing on any CS 101 10. As win be explained in detail later, 
wh^er a Process 610 can in fact access an object in this single address space depends on whether Process 
610 has access rights to the object Other objects, whose UIDs are not unique, may be accessed only by 
Processes 610 executing on CSs 10110 or groups of CSs 10110 for which the nonninique UIO is in fact 
unique. No two objects accessible to a CS 10110 at a given time may have identical UIDs. 

3S The following discussion of objects will first deal with objects as they are seen direcdy by EOS and 
indirectiy by user programs, and then deal with objects as they appear to KOS. 

Hgure 404 illustrates how objects appear to EOS. The object has three parts: the UID 40401, the 
' Attributes 40404, and the Contents, 40406. The object's contents reside in a Logical Allocation Unit (LAU), 
40405. UID 40401 has two parts: a LAU Identifier (LAUID) 40402 that indicates what LAU 40405 the object is 

^ on, and the Object Serial Number (OSN) 40403, which specifies the object in LAU 40405. 

The EOS can create an object on a LAU 40405, and given the object's UID 40401 , can destroy the object 
in addition, EOS can read and change an object's Attributes 40404. Any Process 610 executing on a CS 
10110 may reference information In an object by specifying the object's UID 40401 and the bit in the object 
at which the information begins. At the highest level, addresses in CS 10110 thus consist of a UID 40401 

^ specifying an object and an offset specifying the number of bits into the object at which the information 
begins. As will be explained in detail below, KOS translates such UID-offset addresses Into Intermediate 
forms called AON-offiset addresses for use in JP 10114 and Into page number-displacement addresses for 
use in referencing information which has l^een copied into MEM 10112. 

The physical Implementation and manipulation of objects Is restricted solely to KOS. For instance, 

so objects and their attributes are in fact stored in Secondary Storage 10124. When a program references a 
portion of an object, KOS copies that portion of the object from Secondary Storage 10124 into MEM 10112, 
and if the portion in MEM 10112 is changed, updates the copy of the object in Secondary Storage 10124. 
EOS and user programs cannot control the location of an object In S^ondary Storage 10124 or the location 
of the copy of a portion of an object in MEM 10112, and therefore can access the object only ksy means of 

ss KOS. 

While EOS cannot control the physical implementation of an object, it can provide KOS witi^ 
information that allows KOS to manage objects more effectively. Such information is termed hints. For 
instanoe, KOS generally copies a portion of an object into MEM 10112 only if a Process 610 references 
information in the objeO. However, EOS schedules Process 610 execution, and therefore can predict that 
ceitain objects will be required in the near future. EOS can pass this information on to KOS, and KOS can 
use the information to decide what portions of objects to copy into MEM 10112. 

a Objects and User Programs (fig. 405) 

As stated above, user programs manipulate objects, but the objects are generally not directhr visible to 
65 user programs, instead, user programs use symbols such as variable names or other references to refer to 
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data stored In objects or file names to refer to the objects themselves. The discussion of Namespace has 
already illustrated how CS 10110 compilers translate variable names appearing in statements in 
Procedures 602 into Names, i.e., indexes of NTEs 30401, how Name ResoKre microcode resolves NTB 30401 
into Logtcal Descriptors 27116, and how ATU 10228 translates Logical Descriptors 27116 into locations in 
s MEM 101 12 containing copies of the portions of the objects in which the data represented by the variables 

The translation of filenames to UIDs 40401 is accomplished by EOS. EOS maintains a filename 
translation table which establishes a relationship between a system filenanne called a pathname and the 
UID 40401 of the ob|ecC containing the file's data, and thereby associates the pathname with the object A 
Pathname Is a sequence of ASCII characters which identifies a file to a user of CS 1 01 10. Each pathname in 
a gh^ CS 1011 0 must be unique. Rgure 405 shows the filename translation table. Referring to that figure, 
when a user gives pathname 40501 to the EOS, EOS uses Filename Translation Table 40503 to translate 
pathname 40501 into UtD 40401 for object 40504 containing the file. An object in CS 10110 may thus be 
identified in two ways: by means of its UID 40401 or by means of a Pathname 40501. While an object has 

IS only a single UID 40401 throughout its life, the object may have many Pathnames 40501 . All that is required 
to change an object's pathname 4<^1 is the substitution of one Pathname 40501 for anothCT in the object's 
Entry 40502 in RIename Translation Table 40503. One consequence of the fact that an object may have 
different Pathnames 40501 during Its life is that when a program uses a Pathname 40501 to identify an 
object, a user of CS 10110 may make the program process a different object simply by giving the object 

20 which formeriy had Pathname 40501 which appears in the program a new Pathname 40501 and giving the 
next object to be processed the Pathname 40501 which appears in the program. 

In the present embodiment an object may contain only a single file, and consequently, a Pathname 
40501 always refers to an entire object In other embodiments, a Pathname 40501 may refer to a portion of 
an object and in such embodiments, RIename Translation Table 40503 will associate a Pathname 40501 

25 with a UID-offset address specifying the beginning of the file. 

: b. UIDs 40401 (Rg. 4(») 

UIDs 40401 may identify objects and other entitles tn CS 101 1 0. Any entity Identified by a UID 40401 has 
only a single UID throughout its life. Rgure 4(» is a detailed representation of a CS 101 10 UID 40401. UID 
30 40401 is 80 bits long, and has two fields. Reld 40402, 32 bits long, is the Logical Allocation Unit identifier 
(LAUID). It spacffies LAU 40405 comaining the object LAUiD 40402 is further subdhrided into two subfields: 
LAU Group Number (LAUGN) 40607 and LAU Serial Number (LAUSN) 40605. LAUGN 40607 specifies a 
group of LAUs 40405, and LAUSN 4(m05 specifies a LAU 40405 In that group. Purchasers of CS 101 10 may 
obtain LAUGNs 40607 from the manufacturer. The manufacturer guarantees that he will assign LAUGN 
as 40607 given the purchaser to no other CS 101 10, and thus these LAUGIMs 40607 may be used to form UIDs 
40401 which will be unique for all CSs 10110. Reld 40604, 48 bits iong^ is the Object Serial Number (OSN). It 
specifies the object in LAU 40405. 

UIDs 40401 are generated by KOS Procedure 602. 

There are two such procedures 602, one which generates UIDs 40401 v/hich identify c^jects, and 

40 another which generates UIDs 40401 which identify other entities in CS 101 10. The former Procedure 602 is 
called Generate Object UID, and the latter Generate Non-object UID. The Generate Object UID Procedure 
602 is called only by the KOS Create Object Procedure 602. Create Object Procedure 602 provides Generate 
Object UID Procedure 602 with a LAUiD 40402, and Generate Object UID Procedure 602 returns a UID 40401 
for the object In the presem embodiment UID 40401 is formed by taldng the current value of the 

45 architectural docK contained in a location In MBM 10112, forming an OSN 40403 from the architectural 
clodc's current value, and concatenating OSN 40403 to LAUID 40402. 

Generate Non-object UID Procedure 602 may be invoked by EOS to provide a UID 40401 which does 
not specify an object Non^bject UIDs 40401 may be used in CS 10110 wherever a unique label is required. 
For example, as will be explained in detail later, all Virtual processors 612 which are available to CS 101 10 

so have non-object UIDs 40401. All such non-object UIDs 40401 have a single LAUSN 40607, and thus, EOS 
need only provide a LAUGN 40605 as an argument Generate Non-object UID Procedure 602 concatenates 
LAUGN 40605 with the spedal LAUSN 40807. and LAUID 40402 thus produced with an OSN 40403 obtained 
from the architectural clock. In other embodiments, OSNs 40403 for both object and non-object UIDs 40401 
may be generated by other means, such as counters. 

ss CS 10110 also has a special UID 40401 called the Null UID 40401. The Null UID 40401 contains nothing 
but 0 bits* and is used in situations which require a UID value which cannot represent an entity in CS 1 01 1 0. 

c. Object Attributes 

What a program can do vwth an object is determined by the object's Attributes 40404. There are two 
eo kinds of Attritujtes 40404: Object Attributes and Control Attributes. Object Attributes describe the object's 
contents: Control Attributes control access to the object Objects may have Attributes 40404 even though 
they have no Contents 40406, and in some cases, objects may even exist solely for their Attributes 40404. 

For the purposes of this discussion, there are two kinds of Object Attributes: the Size Attribute and the 
Type Attributes. ^ 
Gs An object's Size Attribute indicates the number of bits that the object currently contains. On each 
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reference to an object's Contents 40406, KOS checks to make sure that the data accessed does not extend 
beyond the end of the object If it does, the reference is aborted. 

The Type Attnbutes indicate what kind of information the object contains and how that infomnation 
may be used. There are three categories of Type Attributes: the Primitive Type Attributes, the Extended 
* Type Attn'bute, and the Domain of Execution attribute. An object's Primitive lype Attribute indicates 
whether the object is a data object, a Procedure Object GOB, an Extended Type Manager, or an S-interpreter. 
As their names imply, data objects contain data and Procedure Obje<^ 608 contain Procedures 602. 
Extended Type Managers (ETMs) are a special type of Procedure Object 608 whose Procedures 608 may 
perform operations solely on objects called Extended Type Objects. Extended Type Objects (ETOs) are 
objects which have an Extended Type Attribute in addition to their Primitive Type Attribute; for details, see 
the discussion of the Extended Type Attribute below. S-tnterpreters are objects that contain interpreters for 
S-languag^ In the present embodiment the interpreters consist of dispatch tables and microcode, but in 
other embodiments, the Interpreters may themselves be written in high-level languages. Like the Length 
Attribute, the Primitive Type Attributes allow KOS to ensure that a program is using an object correctly. For 
instance, when the KOS executes a call for a Procedure 602 it checks whether the object specified by the call 
Is a Procedure Object 608. if it is not« the call fails. 

d. Attributes and Access Control 

The remaining Object Attributes and the Control Attributes are all part of CS 10110's Access Control 

^ System. The Access Control System Is discussed in detail later; here, it is dealt with only to the extent 
required for the discus»on of objects. In CS 10110, an access of an object occurs when a Process 610 
fetches SINs contained in a Procedure Object 608, reads data from an abject, writes data to an object, or In 
some cases, when Process 610 transfers control to a Procedure 602. The Access Control System checks 
whether a Process 610 has the right to perform the access it is attempting. There are tvwa kinds of access In 

^ CS 10110, Primitive Access and Exteiided Access. Primitive Access is access which the Access Control 
System checks on every reference to an object by a Process 610; Extended Access is access that is checked 
o^ly on user request Primitive access ched(s are performed on every object; extended access checks may 
be performed only on ETOs, and may be perfomied only by Procedures 602 contained in ETMs. 

The means by which the Access Control System checks a Process 61 0's access to an ol^ect are Process 

^ 610*8 subject and the object's Access Control Lists (ACLsK Each Process 610 has a subject made up of four 
UJOs 40401. These UIDs 40401 specify the fbliov^ng: 

— The user for wtiom Process 610 was created. This UIO 40401 Is termed the principal component of the 
subject. 

— Process 610 itself. This UIO 40401 is termed the process component 

^ The domain In which Process 610 Is currently executing. This UID 40401 is termed the domain 
component 

— A user*defined subgroup of subjects. This UID 40401 is termed the tag component 

A domain is a group of objects which may potentially be accessed by any Process 610 which is 
executing a Procedure 602 in one of a group of Procedure Objects 608 or ETMs. Each Procedure Object 608 

* or ETM has a Domain of Execution (DOE) Attribute. This attribute is a UID 40401, and while a Process 610 is 
executing a Procedure 602 in that Procedure Object 608 or ETM, the DOE attribute UID 40401 is the domain 
component in Process 610'$ subject. The DOE attribute thus defines a group of objects which may be 
accessed by a Process 610 executing Procedures ^2 from Procedure Object 608. The group of objects is 
called Procedure Object 6^s domain. As may be seen from the above definition, a subject's domain 

4S component may change on any call to or return from a Procedure 602. The tag componem may change 
whenever the user desires. The principal component and the process component on the other hand, do not 
change for the life of Process 610. 

The ACLs which make up the other half of the Access Control System are attributes of (Ejects. Each 
ACL consists of a series of Entries (ACL£), and each ACLE has two parts: a Subject Tmplate and a set of 

S) Access Privileges. The Subject Template defines a group of subjects, and the set of Access Privileges define 
the kinds of access that subjects belonging to the group have to the object To check whether an access to 
an object is legal, the KOS examines the ACLs. It allows access only if it finds an ACLE whose Subject 
Template match^ the current subject of Process 610 which wishes to make the access and whose set of 
Access Privileges includes the Mnd of access desired by Process 6ia For example, a Procedure Object 608 

ss may have an ACL with two eirtries: one whose Subject Template allows any subject access, and whose set 
of Acc^ Privileges allows only Execute Access, and another whose Subject Template allows only a single 
subject access and whose set of Access Privileges allows Read, Write, and Execute Access. Such an ACL 
allows any user of CS 10110 to execute the Procedures 602 in Procedure Object 608, but only a specified 
Process 610 belonging to a specified user and executing a specified group of Procedures 602 may examine 

& or modify the Procedure 602 in the Procedure Object 

There are two kinds of ACLs. All objects have Primith^e Access Control lisxs (PACLs); ETOs may in 
addition have Extended Access Control Lists (EACLs). The subject portion of the ACLE is the same in all 
ACLs; the two kinds of list differ in the kinds of access they oomrol. The access controlled by the PACL is 
defined by KOS and is checked by KOS on every attempt to gain such access; the access controlled by the 
- * 65 EACL is defined by the user and Is checked only when the user requests KOS to do so. 
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€. Implementation of Objects 

1. Introduction (Rg. 407, 408) ^ u -i . 

The user of a CS 10110 need only concern himself with objects as they have just been descnbed. In 
order for a Process 610 to reference an object, the object's LAU 40405 must be accessible from CS 10110 
s upon which Process 610 is running. Process 610 must know the object's UID 40401, and Process 610's 
current subject must have the right to access the object in the desired manner. Process 610 need know 
neither how the object's Contents 40406 and Attributes 40404 are stored on CS 1 01 1 0's physical devices nor 
the methods CS 1 0110 uses to make the object's Contents 40406 and Attributes 40404 available to Process 
610. 

10 The KOS, on the other hand, must Implement objects on the physical devices that make up CS 101 10. In 

so doing, it must take into account two sets of physical limitations: 

— In logical terms, all CSs 10110 have a single logical memory, but the physical implementation of 
memory in the system is hierarchical: a given CS 10110 has rapid access to a relatively small MEM 
10112, much slower access to a relatively large amount of slow Secondary Storage 10124, and very 

7^ slow access to LAUs 40405 on other accessible CSs 1011 0. 

— UIDs 40401, and even more, subjects, are too large to be handled effJdently on JP 101 14's Internal data 
paths and in JP 10114's registers. 

The means fay which the KOS overaomes these physical limitations will vary from embodiment to 
embodiment. Here, there are presented firs* an overview and then a detailed discussion of the means used 

^0 In the present emljodiment 

The physical limitations of the memory are overcome by means of a Virtual Memory system. Ttie 
Virtual Memory System creates a one-level logical memory by automatically bringing copies of those 
portions of objects required by executing Processes 610 into MEM 10112 and automatically copying altered 
portions of objects from MEM 10112 back to Secondary Storage 10124. Objects thus reside primarily in 

2S Secondary Storage 1 0124, but copies of portions of them are made available in MEM 10112 when a Process 
610 makes a reference to them. Besides bringing portions of objects into MEM 10112, when required, the 
Virtual Memory System keeps track of where in MEM 101 12 the portions are tocated. and when a Process 
610 references a portion of an object that is in MEM 10112, the Virtual Memory System translates the 
reference into a physical location In MEM 10112. 

30 JP 101 14's need for smaller object identifiers and subject identifiers is satisfied by the use of internal 

identifiers called Active Object Numbers (AONs) and Active Sut^ect Numbers (ASNs) inside JP 10114. Each 
timea UID 40401 is moved from MEM 10112 into JP 101 14's registers, it is translated Into an AON, and the 
reverse translation takes place each time an AON Is moved from a JP 101 14's registers to MEM 10112. 
Similariy, the current subjects of Processes 610 which are bound to Virtual Processors 612 are translated 

3S from four UiDs 40401 into small Integer ASNs, and when Virtual Processor 612 Is bound to JP 10114, the 
ASN for the subject belonging to Virtual Processor 612's process 610 is placed in a JP 10114 register. The 
translations from UID 40401 to AON and vioe-versa, and from subject to ASN are performed by KOS. 

When KOS trarwlates UIDs 40401 to AONs and vice-versa, it uses AOT 10712. An AOT 10712 Entry 
(AOTE) for an object contains the object's UID 40401, and the AOTE's index in AOT 10712 Is that object's 

40 AON, Thus, gWen an object's AON, KOS can use AOT 10712 to determine the object's UID 40401, and given 
an obect's UID 40401, KOS can use AOT 10712 to detcrmirte the object's AON. If the object has not been 
referenced recently, there nrwy be no AOTE for the object, and thus no AON for the object's UID 40401. 
Objects that have no AONs are called inacthre objects- If an attempt to convert a UID 40401 to an AON 
reveals that the object is inactwe, an Inactive Object Fault results and KOS must activate the object that is, 

4S H must assign the object an AON and make an AOTE for it 

KOS uses AST 10914 to translate subjects into ASN's. When a Process 610's subject changes, AST 
10914 provides Process 610 with the new subject's ASN. A subject may presently have no ASN assod^ted 
with it Such subjects are termed inactive subjects. If a subject is Inactive, an attempt to translate the subject 
to an ASN causes KOS to activate the subject, that is, to assign the subject an ASN and make an entry for 

so the subject in AST 10914. 

In order to achieve efficient execution of programs by Processes 610, KOS accelerates information that 
is frequently used by executing processes 610. There are two stages of acceleration: 

— Tables that comain the information are wired into MEM 10112, that is, the Virtual Memory System 
never uses MEM 10112 space reserved for the tables for other purposes. 

56 — Special hardware devices in JP 10114 contain portions of the information In the tables. 

MHT 10716, AOT 10712, and AST 10914 are examples of the first stage of acceleration. As previously 
mentioned, these tables are always present in MEM 10112. Address Translation Unh (ATU) 10228 is an 
example of the second stage. As previously explained, ATU 10228 is a hardware cache that contains copies 
of the most recently used MHT 10716 entries. Uke MHT 10716. it translates AON offset addresses into the 

eo MEM 10112 locations that contain copies of the data that the UlD-offset address corresponding to the AON- 
offeet address refers to ATU 10228 is maintained by KOS Logical Address Translation (LAT) microcode. 

Figure 407 shows the rBlationship between ATU 10228, MEM 10112, MHT 10716, and KOS LAT 
microcode 40704. When JP 1 01 14 makes a memory reference, it passes AON-offset Address 40705 to ATU 
10228. If ATU 10228 contains a copy of MHT 10716'6 entry for Address 40705, it immediately produces the 

6S corresponcfing MEM 10112 Address 40706 and transmits the address to MEM 10112, If there is no copy, 
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ATU 10228 produces an ATU Miss Event Signal which invokes LAT microcode 40704 in JP 10114. LAT 
microcode 40704 obtains the MHT entry that corresponds to the AON-offset address from MHT 10716, 
places the entry in ATU 1 0228, and returns. JP 1 01 14 then repeats the reference. This time, there is an entry 
for the reference, and ATU 10228 translates the AOIM address Into the address of the copy of the data 

s contained in MEM 10112. 

The relationship between KOS table, hardware cache, and microcode just described is typical for the 
present embod'nnent of CS 101 10. The table (in this case, MHT 10716), is the primary source of information 
and is maintained by the Virtual Memory Manager Process, v^ile the cache accelerates portions of the 
table and is maintained by KOS microcode that Is invoked by event signals from the cache. 

10^ AOT 10712, AST 10914, and MHT 10716 share another characteristic that is typical of the present 
embodiment of CS 101 10: the tables are constructed in such a fashion that the table entry that performs the 
desired translation is located by means of a hash function and a hash table. The hash function translates 
the large UID 40401, subject or AON into a small.imeger. This integer is the index of an entry in the hash 
table. The contents of the hash table entry is an index into AOT 10712, AST 10914, or MHT 10716, as the 

t5 case may be, and these tables are maintained in such a fashion that the entry corresponding to the index 
provided by the hash table is either the entry that can perform the desired translation or contains 
information that allows KOS to find the desired entry. The entries in the tables furthermore contain the 
values they translate. Consequently, KOS can hash the value, find the entry, and then check whether the 
entry is the one for the hashed value. If it is not KOS can quickly go from the entry located by the hash table 

20 to the correct entry. 

Hgure 408 shows how hashing works in AST 10914 in the present embodiment In the present 
embodiment Subject 40801, i.e., the principal, process, and domain components of the current subject are 
input into Hash Function 40802. Hash Function 40802 produces the index of an entry in ASTHT 10710. 
ASTHT Entry 4(»04 in turn contains the index of an Entry (ASTE) 40806 in AST 10914 These ASTC 40806 

25 indexes are ASN& ASTE 40806 contains the principal, prcx^ess, and domain components of some subject 
and a link field pointing to ASTE 40806'. ASTE 40806' has 0 in its link field, which indicates that it is the last 
link in the chain of ASTES beglning with ASTE 4080a If the hashing of a subject yields ASTE 40806, KOS 
cbmpares the subject in ASTE 40806 with the hashed subject; if they are identical, ASTE 40806's Index in 
AST 10914 is the subject's ASN. If they are not tdenticat KOS uses the link in ASTE 40806 to find ASTE 

30 40806*. It compares the subject in ASTE 40806^ with the hashed subject; if they are identical, ASTE 40806"s 
AST index is the subject's ASN; othenMse, ASTE 40806* is the last entry in the chain, and consequently, 
there is no ASTE 40806 and no ASN for the hashed subject 

In the following, we will discuss the implementation of objects In the present embodim^ In detail, 
beginning with the implementation of objects in Secondary Storage 10124 and proceeding then to CS 

35 10110*8 Active Object Management System, the Access Control System, and the Virtual IMemory System. 

2. Objects in Secondary Storage 10124 (Figs. 409, 410) 

Asdescnbed above, objects are collected into LAUs 40405. The c^i^ects belonging to a LAU 40405 are 
stored in Secondary Storage 10124. Each LAU 40405 oonUins an ot^ect whose contents are a table called 

40 the Ijogical Allocation Unit Directory (LAUD). As its name implies, the LAUD Is a directory of the objects in 
LAU 40405. Each object in LAU including the object containing the LAUDi has an entry in the LAUD. 
Bgure 409 shows the relationship between Secondary Storage 10124, LAU 40405, the LAUD, and objects. 
LAU 40405 resides on a number of Storage Devices 40904. LAUD Object 40302* in LAU 40405 contains 
LAUD 40903. Two LAUDEs 40906 are shown. One contains the attributes of LAUD Ol^ect 40802 and the 

45 location of its contents, and the other contains the attributes of LAUD Ot^ect 40902' containing LAUD 40903 
and the location of its contents. 

KOS us^ a table called the Acdve LAU Table (ALAUT) to locate the LAUD belonging to LAU 40405. 
Rgure 41 0 illustrates the relationship between ALAUT 41 001 , ALAUT Entries 41 002, LAUs 40405, and LAUD 
Objects 40902'. Each LAU 40405 accessible to CS 10110 has an Entry (ALALTTE) 41002 in ALAXST 41001. 

so ALAUTE 4100^ for LAU 40405 includes LAU 4040S's LAUID 40402 and UID 40401 of LAU 40705's LAUD 
Object 400)2', Hence, ghren an object's UID 40401, KOS can use UID 40401's LAUID 40402 to locate 
ALAUTE 41002 for the object's LAU 40405, and can use ALAUTE 41002 to locate LAU 40405's LAUD 40903, 
Once LAUD 40903 has been found, OSN portion 40402 of the object's UID 40401 provides the proper 
LAUDE 40906^ and LAUDE 40806 contains object's attributes and the location of Its contents. 

55 LAUD 40903 and the Procedures 602 that manipulate it belong to a part of KOS termed the Inactive 

Object Manager. The following discussion of the Inactive Object Manager will begin with the manner in 
which an object's contents are represented on Secondary Storage 10124, will then discuss LAUD 40903 in 
detail, and conclude by discussing the operations performed by Inactive Object Manager Procedures 602. 

CO a.a. Representation of an Object's Contents on Secondary Storage 10124 

In general, the manner in which an object's contents are represented on Secondary Storage 10124 
depends completely on the Secondary Storage 10124. If a LAU 40405 is made up of disks, then ihe object's 
contents will be stored in disk blocks. As long as KOS can locate the object's contents, it makes no 
difference whether the storage is contiguous or non-contiguous. 

es In the present embodiment, the objects' contents are stored in files created by the Data General 
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Advance Operating System (AOS) procedures executing on lOS 101 16 These procedures manage files that 
contain objects' contents for KOS. In future CSs 10110, the representation of an object's contents on 
Secondary Storage 10124 will be managed by a portion of KOS. 

S • b.b. LAUD 40903 (fig. 411, 412) ^ ^ ....r.u ^ 

Rgure 411 is a conceptual illustration of LAUD 40903. LAUD 40903 has three parts: LAUD Header 
41102, Master Directory 41105. and LAUD Entries (LAUDEs) 40906. LAUD Header 41102 and Master 
Directory 41105 occupy fixed locations In LAUD 40903, and can therefore always be located from the UID 
40401 of LAUD 40903 given in /UAUT 41 001 . The locations of LAUDEs 40906 are not fixed, but the entry for 

10 an Individual object can be located from Master Directory 41 105. 

Turning first to LAUD Header 41102. LAUD Header 41102 contains LAUID 40402 belonging to LAU 
40405 to which LAUD 40903 belongs and OSN 40403 of LAUD 40903. As will be explained in greater detail 
below. KOS can use OSN 40403 to find LAUDE 40906 for LAUD 40903. 

Turning now to Master Directory 41 105, Master Directory 41 105 translates an object's OSN 40403 into 

w the location of the object's LAUDE 40906. Master Directory 41 105 contains one Entry 41 108 for each object 
in LAU 40505. Each Entry has two fields: OSN Field 41 106 and Offset Field 41 107. OSN Reld 41 106 contains 
OSN 40403 for the object to which Entry 41108 belongs; Offset Field 41107 contains the offset of the 
object's LAUDE 40906 in LAUD 40903, KOS orders Entries 41108 by increasing OSN 40403, and can 
therefore use binary search means to fmd Entry 41108 containing a gh^en OSN 40403. Once Entry 41 108 has 

20 been located. Entry 41108's Offset Reld 41107, combined with LAUD 4O903's OSN 40403, yields the UID 
offset address of the object's LAUDE 40906. 

Once KOS knows the location of LAUDE 40908 It can determine an object's Attributes 40404 and the 
location of its Contents 40406. Figure 411 gwes only an overview of LAUDE 40906's general structure. 
LAUDE 40906 has three components: a group of fields of fixed size 41 109 that are present in every LAUDE 

26 and two variable sized components, one, 41 139, containing entries belonging to the obiecf s PACL, 

and another. 41 141, containing the eject's EACL ^ . * . ^ 

As the preceding descriptions of the LAUD's components imply, the number of LAUDEs 40906 and 
Master Directory Entries 41 108 varies with the number of objects in LAU 40405. Furthermore, the amount of 
space required for an object's EACL and PACL varies from object to object KOS deals with this problem by 

30 including Free Space 41 123 in each LAUD 40903. When an object is created, or when an object's ACLs are 
expanded, the Inactive Object Manager expands LAUD 40903 only if there is no available Free Space 41 123; 
if there Is Free Space 41 123, the Inactive Object Manager takes the necessary space from Free Space 41 123; 
when an object Is deleted or an object's ACLs shortened, the Inactive Object Manager returns the unneeded 
sp^ to Free Space 41123. ^ ^ 

35 figure 412 is a detailed representation of a single LAUDE 4090a Figure 412 presents those fields of 
LAUDE 40906 which are common to all embodiments of CS 10110; fields which may vary from 
embodiment to embodiment are ignored. Starting at the top of Figure 412, Structure Version Reld 41209 
contains information by which KOS can determine which version of LAUDE 40906 ft is dealing with. Size 
Rekf 41211 contains the Size Attribute of the object to which LAUM 40906 belongs. The Size Attribute 

40 specifies the number of bits currently contained in the object Lock Reld 41213 is a KOS lock. As will be 
explained in detail in the discussion of Processes 610, Lock Reld 41213 allows only one Process 610 to read 
or write LAUDE 40906 at a time, and therefore keeps one Process 610 from ahering LAUDE 40906 while 
another Process 610 is reading LAUDE 409(». File Identifier 41215 contains a system identifier for the file 
which contains the Contents 40406 of the object to which LAUDE 40906 belongs. The form of File Identifier 

4$ 41215 may vary from embodiment to embodiment; in the present embodiment, it is an AOS system file 
identifier. UID Reld 41217 contains UID 40401 belonging to LAUDE 4(^'s object Primitive Type Field 
41219 contains a value which specifies the object's Primitive Type. The object may be a data object a 
Procedure Object 608, an ETM, or an S-imerpreter object. AON Field 41 221 contains a valid value only when 
LAUDE 40906's object is active, i.e., has an entry in AOT 10712, AON Reld 41221 then contains the object's 

so AON. If the object is an ETO, Extended Type Attribute Held 41223 contains the UID 40401 of the ETO's ETM. 
OthenMse, it contains a Null UID 40401. Similarly, if the object is a Procedure Object 608 or an ETM, Domain 
of Execution Attribute Field 41225 contains the object's Domain of Execution Attribute, 

The remaining parts of LAUDE 409(» belong to the Access Control System and will be explained In 
detail in that discussion. Attribute Version Number Field 41 227 contains a value indicating which version of 
SS ACLEs this LAUDE 40906 contains, PACL Size Field 41229 and EACL Size Field 41 231 contain the sizes of the 
respective ACLs, PACL Offset Reld 41233 and EACL Offset Field 41235 contain the offsets In LAUD 40903 of 
additional PACLEs 41139 and EACLEs 41141, and fixed PACLEs 41237 contains the portion of the PACL 
which is always included In LAUDE 4(^06. 

60 3, Active Objects {fig, 413) ^ . u . u 

An active object is an object whose UID 40401 has en AON associated with it In the present 
embodiment each CS 10110 has a set of AONs' KOS associates these AONs with UIDs 40401 in such 
fashion that at any given moment an AON in a CS 10110 represents a single UID 40401. Inside FU 10120. 
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AONs are used to represent UIDs CS 101 10. In the present embodiment the AON is represented by 14 bits. 
A 1 1 2-blt UID-offset address (80 bits for UID 40401 and 32 for the offeet) is thus represented inside FU 101 20 
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by a 46-bft AON-offeet address (14 bits for the AON and 32 bits for the offset). 

A CS 10110 has far fewer AONs than there are UIDs 40401 . KOS multiplexes a CS 101 10's AONs among 
those objects that are being referenced by CS 10110 and therefore require AONs as well as UIDs 40401. 
While a given AON represents only a single UiO 40401 at any given time« at different times, a UID 40401 
may have different AONs associated with it 

Rgure 413 provides a conceptual representation of the relationship between AONs and UIDs 40401. 
Each CS 10110 has potential access to 2**80 UIDs 40401. Son>e of these UIDs, however, represent entities 
other than objects, and others are never associated with any entity. Each CS 101 10 also has a set of AONs 
41303 available to it- In the present embodiment, this set may have up to 2**14 values. Since the AONS are 
only used internally, each CS 10110 may have the same set of AONs 41303. Any AON 41304 in set of AONs 

41303 may be associated with a single UID 40401 in set of object UIDs 41301. At different times, an AON 

41304 may be associated with different UIDs 40401. 
As mentioned above, KOS associates AONs 41304 with UIDs 40401. It does so by means of AOT 10712. 

Each AOT entry (AOTE) 41306 in AOT 10712 associates a UID 40401 with an AON 41304, AON 41304 is the 
index of AOTE 41306 which contains UID 40401. Until AOTE 41306 is changed, the AON 41304 which is the 
index of AOTE 41306 containing UID 40401 represents UID 40401. AOT 10712 also allows UIDs 40401 to bo^ 
translated into AONs 41303 and vice-versa. Rgure 413 illustrates the process for UID-oflset Address 41308* 
and AON^ffset Address 41309. AOTE 41306 associates AON 41304 in AON-offset Address 41309 with UID 
40401 in UlD-offset Address 41308, and Addresses 41308 and 41309 have the same Offset 41307. 
Consequently, AON-offset Address 41309 represents UlD-offset Address 41308 inside JP 101 14. Since both 
addresses use the same Offset, AMress 413C3 can be translated into address 41308 by translating Address 
41309'$ AON 41304 into Address 41308*s UID 40401, and Address 41308 can be trandated into Address 
41309 by the reverse process. In both cases, the translation is performed by finding the proper AOTE 41306. 

The process by which an object becomes acdve is called object activation. A UlD-offeet Address 41308 
cannot be translat&j into an AON-offset Address 41309 unless the objea to which UID 40401 of UlD-of^ 
Address 41308 belongs Is active. If a Process 61 0 attempts to perform such a translation using a UID 40401 
belonging to an inactive object an Inactive Object Fault occurs. KOS handles the fault by removing Process • 
610 that attempted the translation from JP 10114 until a special KOS Process called the Object Manager 
Process has activated the object. After the object has been activated. Process 610 may return to JP 10114 
and complete the UID 40401 to AON 41304 translation. 

The portion of KOS that manages acth^e ob^scts is called the Active Object Manager (AOM). Parts of the 
AOM are FYocedures ^2, and parts of it are microcode routines. The high-level language components of 
the AOM may be invoiced only by KOS processes 610. KOS Active Object Manager Process 610 performs 
most of the functions irwolved in active object management 

a.a. UID 40401 to AON 41304 Translation 
Generally speaking. In CS 10110, addresses stored in MEM 10112 and Secondary Memory 10124 are 
stored as UID offset addresses. The only form of address that FU 10120 can translate into a location in MEM 
10112 is the AON-cflset form. Consequently, each time an address is loaded from MEM 10112 into a FU 
^ 10120 register, the address must be translated from a UlD-offeet address to an AON-offset address. The 
reverse translation must be performed each time an address Is moved from a FU 10120 register back into 
memory. 

Such translations may occur at any tima For example, a running AHrtual Processor 612 performs such a 
translation when the Process 610 being executed fay Virtual Processor 612 carries out an indirect mernory 

^ reference. An indirect nnemory reference is a reference which first fetches a pointer, that is, a data item 
whose value is tlie address of another data item, and then uses the address contained in the pointer to fetch 
the data itself. In CS 10110, pointers represent UlD-offset addresses. Virtual Processor 612 performs the 
indirect memory reference by fetching the pointer from MEM 10112, placing It in FU 10120 registers, 
translating UH^ 40401 represented by the pointer into AON 41304 associated with It, and using the resulting 

so AON-offset address to access the deta at the location specified by the address. 

Most such translations, however, occur when Virtual Processor 612 state is saved or restored. For 
instance, when one Process 610's Virtual Processor 612 is removed from JP 10114 and another Process 
610*8 Virtual Processor 612 is bound to JP 10114, the state of Virtual Processor 612 being removed from JP 
101 14 is stored in memory, and the state of Virtual Processor 61 2 being bound to JP 101 14 is moved into JP 

ss 10114's registers. Because only UlD-offset addresses may be stored in memory, ail of the AON-offset 
addresses in the state of Virtual Processor 612 which is being removed from JP 10114 must be translated 
into UID-offset addresses. Similarly, al! of the UID-offset addresses in the state of Virtual Processor 612 
being bound to JP 10114 must be trar^lated into AON-offset addresses before they can be loaded into FU 
10120 registers. 

C The Acc^s Control System 

As mentioned in the introduction to objects, each time a process 610 accesses data or SlNs in an object, 
the KOS Access Control System checks whether Process 610's current subject has the right to perform the 
kind of access that Process 610 is attempting. If Process 610's current subject does not have the proper 
. & access, the Access Control System aborts the memory operation which Process 610 was attempting to 
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carry out. The fotlowing discussion presents details of the implementation of the Access Control System, 
beginning with subjects, then proceeding to subject templates, and finally to the means used by KOS to 
accelerate access checking. 

5 a. Subjects 

A Process 610*8 subject Is part of process 610's state and is contained along with other state belonging 
to Process 610 in an object called a Process Object Process Objects are dealt with at length in the detailed 
discussion of Processes 610 which follows the discussion of objects. While a subject has, as mentioned 
above, four components, the principal component, the process component, the domain component, and 
the tag component, the Access Control System in the present embodiment of CS 101 1 0 assigns values to 
only the first three components and ignores the tag component when checking access. 

In the present embodiment, the UIDs 40401 which make up the components of a Process 610'8 subject 
are the UIDs 40401 of objects containing infomiation about the entities represented by the UIDs 40401 . The 
principal component's UID 40401 represents an object called the Principal Object The Principal Object 

^5 contains information about the user for whom Process 610 was created. For example, the information 
might corwern what access rights the user had to the resources of CS 101 10, or it might contain records of 
his use of CS 101 10. The process component's UID 40401 represents the Process Object, while the domain 
component's UID 40401 represents an object called the Domain Object. The Domain Object contains 
information which must be accessible to any Process 610 whose subject has the Domain Object's UID 

^ 40401 as its domain component. Other embodiments of CS 10110 will use the tag component of the 
subject In these embodiments, the tag component's UID 40401 Is the UID 40401 of a Tag Object containing 
at least such information as a list of the subjects which make up the group of subjects represented by the 
tag component's UID. 

Z$ b. Domains 

As stated above, the subject's domain component is the domain of execution attribute belonging to the 
Procedure Object 608 or ETM whose code Is l)eing executed when the access request is made. The domain 
component of the subject thus gives Process 610 to which the subject belongs potential access to the group 
of objects whose ACLs have ACtEs with subject templates containing domain components that match the 

30 IXDE attribute. This group of objects is the domain defined by the Procedure Object 608 or ETM's DOE 
attribute. When a Process 610 executes a Procedure 602 from a Procedure Object 608 or ETM with a gh/en 
DOE attribute. Process 610 is said to be executing in the domain defined by that DOE attribute. As may be 
Inferred from the above, different Procedure Objects 608 or ETMs may have the same DOE attribute, and 
objects may have ACLEs which make them members of many dHfferent domains. 

X In establishing a relationship between a group of Procedure Objects &)8 and another group of objects, 

a domain allows a programmer using CS 101 10 to ensure that a gh^en object is read, executed, or modified 
only by a oertam set of Procedures «)2. Donuiins may thus bB used to construct protected subsystems in 
CS 10110. One example of such a protected subsystem Is KOS HseK: the objects in CS 10110 which contain 
KOS tables all have ACLs vtrhose domain template components match only the DOE which repres<mt5 the 

40 KOS domain. The only Procedure Objects 608 and ETMs which have this DOE are those which contain KOS 
Procedures 602, and consequently, only KOS Procedures 602 may manipulate KOS tables. 

Since an obiect may belong to more than one domain, a programmer may use domains to establish 
hierarchies of access. For example, if some of the objects in a first domain belong both to the first domein 
and a second domain, and the second domain's objects all also belong to the first domain, then Procedures 

45 602 contained in Procedure Objects 608 whose DOEa define the first domain may access any object in the 
firet domain, Indudtng those which also belong to the second domain, while those from Procedure Objects 
608 whose DOES define the second domain may access only those objects in the second domain. 

c Access Control Lists 

so As previously mentioned, the Access Control System compares the subject belonging to Process 610 

maWng an access to an object and the kind of access Process 610 desires to make with the object's ACLs to 
determine v\^ether the access is legal. The following discussion of the ACLs will first deal with Subject 
Templates, since they are common to all ACLs, and then with PACLs and EACLs. 

ss 1. Subject Templates (Rg. 416) 

Rgure 416 shows Subject Templates, PACL Entries (PACLEs), and EACL Entries (EACLEs). Tuming first 
to the Subject Templates, Subject Template 41 601 consists of four components, Principal Template 41606, 
PfX)cess Template 41607, Domain Template 41609, and Tag Template 41611. Each template has two fields, 
Ravor Raid 41603, and UID Raid 41605. Ravor Field 41603 indicates the way in which the teniplate to which 

60 it belongs is to match the corresponding component of the subject for Process 610 attempting the access. 
Ravor Reld 41603 mey have one of three values: match any, match one, match group. K Ravor Reld 41603 
has the value nwtch any, any subject component UID 40401 matches the template, and the Access Control 
System does not examine UID Field 41605. If Ravor Reld 41«)3 has the value match one, then the 
corresponding subject component must have the same UID 40401 as the one contained In UID Field 41605. 

65 If Ravor Reld 41603 has the value match group, finally, then UID Reld 41605 contains a UID 40401 of an 
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object containing Information about the group of subject components which the given subject component 
may match. 

2. Primitive Access Control Lists (PACLs) 

5 PACU are made up of PACUEs 41613 as illustrated in Figure 416. Each PACLE 41613 has two parts; a 

subject template 41601 and an Access Mode Bits Field 41615. The values in Access Mode Bits Reld 41615 
define 1 1 kinds of access. The eleven kinds fall into two groups: Primitive Data Access and Primitive Non- 
data Access, Primitive Data Access controls what the subject may do with the object's Contents 
Primitive Non^ata Access controls what the subject may do with the object's Attributes 40404. 

10 There are three kinds of Primitive Data Access: Read Access. Write Access, and Execute Access. If a 

subject has Read Access, it can examine the data contained in the object; if the subject has Write Access, it 
can alter the data contained in the object; if it has Execute Access, it can treat the data in the object as a 
Procedure 602 and attempt to execute it A subject may have none of these kinds of access, or any 
combination of the kinds. On every reference to an object, the KOS checks vifhether the subject performing 

15 the reference has the required Primitive Data Access. 

Primitive Non-data Access to an object is required only to set or read an object's Attributes 40404, and 
is checked only when these operations are performed. The kinds of Non-data Access correspond to the 
kinds of Attributes 40404: 

20 Attributes S.^'^''^' ^ IQnd of Access 



$0 



as 



Object Attributes get object attributes 

set object attributes 

Primitive Control get primitive control 

attributes 

Attributes set primitive control 

attributes 

Extended Control get extended comrol 

Attributes attributes 

set extended control 
attributes 

ETM Access i^asETM 

create ETO 



40 The access rights for ot>tect attributes allow a sul^ect to get and set the object attributes described 
previously. The access rights for primitive and extended control attributes allow a subject to get and set an 
object's PACL and EACL respectively. 

An object may have any number of PACLE8418t3 in Its PAOLThe firstfh^e PACLEs 41613 In an ol^ecf s 
PACL are contained in fixed PACL£ Reld 41237 of LAUDE 40906 for the object; the remainder are stored tn 

45 LAUD 40903 at the location specified in PACL Offset Held 41233 of LAUDE 40906. 

3. APAM 10918 and Protection Cache 10234 (Rg. 421 ) 

Primitwe non-data access rights are checked only when users invoke KOS routines that require such 
access rights, and extended access rights are checked only when users request such checks. Primitive data 

SB access rights, on the other hand, are checked every time a Virtual Processor 61 2 makes a memory reference 
while executing a Process 610. The KOS implementation of primitive data access right checking therefore 
emphasizes speed and efficiency. There are two parts to the implementation: APAM 10918 in MEM 10112^ 
and Protection Cache 10234 in JP 10114. APAM 10918 is in a location In MEM 10112 known to KOS 
microcode. APAM 10918 contains prin«tive data access information copied from PACLEs 41613 which 
tielong to active objects and whose Subject Template 41601 niatches an active subject Protection Cache 
10234, in turn, comain copies of the infomiation in APAM l<B18forthe active subject of Process 610 whose 
Virtual Processor 612 is currently bound to JP 10114 and active objects referenced by Process 610. A 
primitive data access check in CS 101 10 begins with Protection Cache 10234^ and if the information is not 
contained in Protection Cache 10234, proceeds to APAM 10918, and if it is not there, finally, to the object's 

£0 PACL The discussion which follows begins whh APAM 10918. 

Rgure421 shows APAM 10918, APAM 10918 is organized as a two-dimensional array. The array's row 
indexes are AONs 41304, and its column indexes are ASNs. There is a row for each AON 41 304 in CS 101 10, 
and a column for each ASN. In Figure 421, only a single row and column are shown. Any primitive data 
access infomnation in APAM 10918 for tiie object represented by AON 41304 j is contained In Row 42104, 

^ while Column 42105 contains any primitive data access information in APAM 1(^18 for the subject 
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represented by ASN k. APAM Entry (APAME) 42106 Is at the Intersection of Row 42104 and Column 42105, 
and thus contains the primitive data access infonnation from that PACLE 41613 belonging to the object 
represented by AON 41304 j whose Subject Template 41601 matches the subject represented by ASN k. 
An expanded view of APAWIE 42106 is presented beneath the epre^ntation of APAM 10918, APAME 
^ 42106 contains four Vbit fields. The bits represent ^e kinds of primitive data access that the subject 
represented by APAME 42106's column index has to the object represented by APAME 421 06^$ row index* 

— Field 42107 is the Valid Bit If the Valid Bit is set, APAME 42108 contains whatever primitive data access 
information is available for the subject represented by the column and the object represented by the 
row. The remaining fields in APAME 42106 are meaningful only if Valid Bit 42107 is set 

— Field 42109 Is the Execute Bit If it Is set, APAME 4210^5 subject has Execute Access to APAME 421 O&s 
object. 

— Reld 42111 is the Read Bit If It is set, APAME 421 OS's subject has Read Access to APAME 42106*8 
object. 

— Field 42113 is the Write Bit if it fis set APAME 42106-8 subject has Write Access to APAME 42106'8 
» object, 

Ariy combination of bits in Fields 42109 through 421 13 nnay be set If all of these fields are set to 0, 
APAME 42106 indicates that the subject it represents has no aco^ to the ol^ect it represents. . 

KOS sete APAME 42106 for an ASN and an AON 41304 the first time the subject represented by the 
ASN references the object represented by AON 41304. Until APAME 42106 is set Valid Bit 421 07 is set to 0. 
^ When APAME 42106 is set. Valid Bit 42107 is set to 1 and Helds 42109 through 42113 are set according to 
the primitive data access information in the object's PACLE 41613 whose Subject Template 41601 matches 
the subject When an object is deacthfated. Valid Bits 42107 in all APAMEs 42106 In the row belonging to the 
object's AON 41304 are set to 0; simiiarty, when a subject Is deactivated. Valid Bits 42107 in all APAMEs 
42106 in the column belonging to the subject's ASN are set to 0. 

4. Protection Cache 10234 and Protection Checking (Fig. 422) 

The final stage in the acceleration of protection information Is Protection Cache 1 0234 in JP 101 1 4. The 
details of the way in whk:h Protection Cache 10234 functions are presented In the discussion of the 
hardware; here, there are discussed the manner in which Protection Cache 10234 performs access checks, 

30 the reiationship between protection Cache 10234, APAM 1(»18, and AOT 10712, and the manner in which 
KOS fmytection cache microcode maintains Protection Cache 10234. 

Rgure 422 is a block diagram of Protection Cache 10234, AOTE 10712, APAM 10918, and KOS 
Microcode42207wlUch maintains Protec^'on Cache 10234. Each time JP 10114 makes a memory referw^e 
using a Logical Descriptor 27116, It amuHaneousiy presets Logical Descriptor 27116 and a Signal 42208 

35 indicating tiie kind of memory operation to Protection Cache 10234 and ATU 10228. Entries 4221 S in 
Protection Cache 10234 contain primitive data access and lengtfi information for objects previously 
referenced by the current subject of Process 610 whose Virtual Processor 512 is currently bound to JP 
10114. On every memory reference. Protection Cache 10234 emits a Valid/invalid Signal 42205 to MEM 
10112. If Protection Cache 10234 contains no Entry 42215 for AOtSI 41^ contained in Logical Descriptor 

40 271 1 6's AON field 271 1 1 , if Entry 4221 5 indicates that the subject does not have the type of access required 
by process 610, or if the sum of Logical Descriptor 271 16*s OFF field 27113 and LEN field 271 15 exceed the 
object's current size. Protection Cache 10234 emits an Invalid Signal 42205. This signal causes MEM 101 12 
to abort the memory reference. Othemlse, Protection Cache 10234 emits a Valid Signal 42205 and MEM 
10112 executes the memory ref^ence. 

^ When Protection Cache 1 0234 emits an Invalid Sig nal 42205, it latches Logical Descriptor 271 1 6 used to 

make the reference into Descriptor Trap 20256, the memory command into Command Trap 27018, and if it 
was a write operation, the data into Data Trap 20258, and at the same time emits one of two Event Signals 
to KOS microcode. Ulegai Access Event Signal 42208 occurs when Process 610 making the reference does 
not have the proper ao^ess rights or the data referenced extends beyond the end of the object, lilegal 

so Access Event Signal 422(^ invokes KOS microcode 42215 which performs a Microcode to Software Call 
42217 (described in the discussion of Calls) to KOS Access Control System Procedures 602 and passes the 
contents of Descriptor Trap 20256, Command Trap 27018, the ASISl of Process 610 (contained in a register 
MGR's 10360), and if necessary. Data Trap 20258 to these Procedures e02. These procedures 602 inform 
EOS of the protection violation, and EOS can then remedy it 

ss Cache Miss Event Signal 42206 occurs when there is no Entry 42215 for AON 41304 in protection Cache 
10234. Cache Miss Event Signal 42206 invokes KOS Protection Cache Miss Microcode 42207, which 
constructs missing Protection Cache Entry 42215 from information obtained from AOT 10712 and APAM 
1(»18. If APAM 10918 contains no entry for the current subject's ASN and the AON of the object being 
referenced, protection Cache Miss Microcode 42207 performs a Microcode-to-software Call to KOS Access 

€0 Control System Procedures 602 which go to LAUDE 40906 for the object and copy the required primitive 
data access Information from the PACLE 41613 belonging to the object whose Subject Template 41601 
matches the subject attemptir^ the reference into APAM 10918. The KOS Access Control System 
Procedures 602 then return to Cache Miss Microcode 42207, which itself retums. Since Cache Miss 
Microcode 41107 was invoked by an Event Signal, the retum causes JP 10114 to reexecute the memory 

6S reference which caused the protection cache miss. If protection Cache 10234 was loaded as a result of the 
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last protection cache miss, the miss docs not recur; if Protection Cache 10234 was not loaded because the 
required information was not in APAM 10918, the miss recurs, but since the information was placed in 
APAM 10918 as a result of the previous miss. Cache Miss Microcode 42207 can now construct an Entry 
42215 in Protection Cache 10234. When Cache Miss Microcode 42207 returns, the memory reference is 
. ^ again attempted, but this time Protection Cache 10234 contains the information and the miss does not 
recur. 

Cache Miss Microcode 42207 creates a new Protection Cache Entry 42215 and loads it into Protection 
Cache 10234 as follows: Using AON 41304 from Logical Descriptor 27116 latched into Descriptor Trap 
20256 when the memory reference which caused the miss was executed and the current subject's ASN, 
contained In GR's 10360, Cache Miss Microcode locates APAME 42106 for the subject represented by the 
ASN and the object represented by AON 41304 and copies the contents of APAME 42106 into a JP 10114 
register which may serve as a source for JPD Bus 10142. tt also uses AON 41304 to locate AOTE 41306 for 
the obiect and copies the contents of Size Field 41519 into another JP 10114 register which Is a source for 
JPD Bus 10142. tt then uses three special microcommands, executed in successive microinstructions, to 
load. Protection Cache Entry 4221 5. The first miciocommand loads Protection Cache Entry 4221 5's TS 2401 0 
with AON 41304 of Logical Descnptor 27116 latched into Descriptor Trap 20256; the second loads the 
object's size into Protection Cache 10234's EXTENT field, and the third loads the contents of APAME 42106 
in the same fashion. 

Another microcommand invalidates all Entries 4221 5 in Protection Cache 10234. This operation, called 
^ flushing, is performed when an objetit is deactivated or when the current subject changes. The current 
subject changes whenever a Virtual Processor 612 is unbourKl from JP 101 14, and whenever a Process 610 
performs a call to or a return from a Procedure 502 executing in a domain different from that in which the 
calling Procedure 602 or the Procedure 602 being returned to executes in. In the cases of the Call and the 
unbinding of Virtual Processor 61 2, the cache flush is p^ormed by KOS Call and dispatching microcode; in 
^ the case of object deacthmtion, it is performed t)y a KOS procedure using a special KOS SIN which invokes 
Cache Flush Microcode. 

D. Processes 

1. Synchronization of Proc^es 610 and Virtual Processors 612 

30 Since Processes 610 and the Virtual Processors 612 to which they are bound may execuite concurrently 

on CS 10110, KOS must provide means for syndironizing Processes 610 which depend on each other. For 
example, if process 610 A cannot proceed until Process 610 B has performed some operation, there must 
be a mechanism for suspending A's execution until B is finished. Generally speaking, four kinds of 
synchronization are necessary: 

3s — One Process 610 must be able to halt and wait for another Process 610 to finish a task before it 
proceeds. 

— One Process 610 must be able to send another Process 610 a message and wait for a reply before it 
proceeds. 

— When processes 610 share a data base, one Process 610 must be able to exclude other Processes 610 
40 from the data base until the first Process 610 is finised using the data base. 

— One Process 610 must be able to interrupt another Process 610, i.e., asynchronously cause the second 
Process 610 to perform some action. 

KOS has internal mechanisms for each land of synchronization, and in addition supplies 
synchronization mechanisms to EOS. KOS uses the internal mechanisms to synchronize Virtual Processors 
<5 612 and KOS Processes 610, while EOS uses the medianisms supplied by KOS to synchronize all o^er 
Processes 610. The internal mechanisms are the following: 

— Event counters. Await Entries, and Await Tables. As will be explained in detail below. Event Counters 
and Await EmHes allow one Process 610 to halt and watt for another Process 610 to complete an 
operation. Event counters and Await Entries are also used to implement process interrupts. Await 

so Entries are organized into Await Tables. 

— Message Queues. Message Queues allow one Process 610 to send a message to another and wait for a 
reply. Message Queues are implemented with Event Counters and queue data structures. 

— Locks. Locks allow one Process 610 to exclude other Processes 610 from a data base or a segment of 
code. Locks are implemented with Event Counters and devices called Sequencers. 

ss KOS makes Event Counters, Await Entries, and Message Queues available to EOS. It does not provide 

Locks, but it does provide Sequencers, so that EOS can construct its own Locks. The following discussion 
will define and explain the logical properties of Event Counters, Await Entries, Message Queues, 
Sequencers, and Locks. Their implementation In the present embodiment will be described along with the 
implementation of Processes 610 and Virtual Processors 612. 

€0 

a. Event Counters 44801, AwaH Entries 44804, and Await Tables (Rg. 448, 449) 

Event Counters, Await Entries, and Await Tables are the fundamental components of the KOS 
Synchronization System. Rgure 448 illustrates Event Counters and Await Entries in the present 
embodiment Figure 449 gives a simplified representation of Process Event Table 44705, the present 
£5 embodiment's Await Tables. Turning first to Rgure 448, Event Counter 44801 is an area of memory which 
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contains a value tiiat may only be increased. In one of the present embodiment Event Counters 44801 for 
KOS sv^ems which may not page fault are always present In MEM 10112; other Event Counters 44801 are 
stored in Secondary Storage 10124 unless a Process 610 has referenced them and thereby caused the VMM 
System to load them into MEM 101 12. The value contained in an Event Counter 44801 Is termed an Event 
^ Counter Value 44802. In the present embodiment, EventCounter 44801 contains 64 bits of data, of which 60 
make up Event Counter Value 44802. Event Counter 44801 may be referred to either as a variable or by 
means of a 128-bit UID pointer which contains Event Counter 44801 's location. The UID pcwnter istemied an 
Event Counter Name 44803. 

Await Entry 44804 is a component of entries in Await Tables. In the present embodiment, there are two 
Await Tables: Process Event Table 44705 and Virtual Processor Await Table (VPAT) 45401. VPAT 46401 is 
always present In MEM 10112. As already mentioned. Figure 449 illustrates PET 44705. Both PET 44705 and 
UPAT 45401 will be described in detail later Each Await Entry 44804 contains an Event Counter Name 
44803, an Event Counter Value 44802, and a Back Link 44805 which identifies a Process 610 or a Virtual 
Processor 612. Await Entry 44804 thus establish^ a relationship between an Event Counter 44801, an Event 
Counter Value 44802, and a Process 610 or Virtual processor 61 2» 

Turning now to Rgure 449, In the present embodiment, all Await Entries 44804 for user Processed 61 0 
are contained in PET 44705. PET 44705 also contains other information. Rgure 449 presents only those 
parts of PET 44705 which illustrate Await Entries 44804. PET 44705 Is structured to allow rapid location of 
Await Entries 44804 belonging to a specific Event Counter 44801. PET entries (PETEs) 44909 contain links 
^ which allow them to be combined into lists in PETE 44705. There are four kinds of lists in PET 44705: 

— Event counter lists: these lists link all PETEs 44909 for Event Counters 44801 whose Event Counter 
Names 44803 hash to a single value. 

— Await lists: These lists link all PETEs 44909 for Event Counters 44801 which a given Process 610 is 
awaiting. 

— Interrupt lists: These lists link all PETEs 44909 for Event Counters 44801 which will cause an Interruptto 
occur for a gh fen P rocess 610. 

— The Free list: PETEs 44909 which are not being used In one of the above lists are on a free list 
Each PETE 44909 Which is on an await list or an interrupt List is also on an event counter list* 
Turning first to the event counter lists, all PETEs 44909 on a given event counter list contain Event 

^ Counter Names 44803 which hash to a single value. The value is produced fay Hash Function 44901, and 
then used as an index in PET Hash Table (PETHT) 44903. That entry in PETHT 44903 contains the index in 
PET 44705 of that PETE 44809 which is the head of the event counter l ist PETE List 44904 represents one 
such event counter list Thus, ghmn an Event Counter Name 44803, KOS can quickly find all Await Entries 
44804 belonging to Event Counter 44801. 

3S In the present emlMdiment, the implementation of Event Counters 44801 and tables with Await Entries 
44804 invoh^es both Processes 61 0 and Virtual Processors 61 2 to which Processes 610 are bound. As will be 
explained later, a large number of Event Counters 44^1 and Await Entries 44804 belonging to Processes 
61 0 are multiplexed onto a small number of Event Counters 44801 and Await Entries 44804 belonging to the 
Processes' Virtual Processors 612. Await entries 44804 for Event Counters 44801 belonging to Virtual 

40 Processors 612 are contained in VPAT 45401 . 

b. Synchroi^ion with Event Counters 44801 and Awaft Entries 44804 

. The simplest form of Process 610 synchronization pro\^ded by KOS uses only Event Counters 44801 
and Await Entries 44804. Coordination takes place like this: A Process 610 A requests KOS to perform an 

^ Await Operation, i.e., to establish one or more Await Entries 44804 and to suspend Process 610 A until one 
of the Await Entries is satisfied. In requesting the Await Operation, Process 610 A defines what Event 
Counters 44801 it is awaiting and what Event Counter Values 44802 these Event Counters 44801 must have 
for their Await Entries 44804 to be satisfied. After KOS establishes Await Entries 44804, it suspends Process 
61 0 A. lA^ile process 610 A is suspended, other Pr<H»sses 61 0 request KOS to perform Advance Operations 

60 on the Event Counters 44801 specified in Process 610 A's Await Entries 44804. Each time a Process 610 
requests an Advance Operation on an Event Counter 44801, KOS increments Event Counter 44801 and 
chedcs Event Counter 4480V5 Await Entries 44804. Eventually, one Event Counter 44801 satisfies one of 
Process 610 A's Await Entries 44804, i.e., reaches a value equal to or greater than the Event Counter Value 
44802 specifted in its Await Entry 44804 for process 610 A. At this point KOS allows process 610 A to 

ss resume execution. As process 610 A resumes execution. It deletes all of its Await Entries 44804. 

E. Virtual Processors 612 {fig, 453) 

As previously stated, a Virtual processor 612 may be logically defined as the means by which a Process 
610 gains access to JP 101 14. In physical terms, a Virtual Processor is an area of MEM 101 12 which contains 

fio the information that the KOS microcode which binds Virtual Processors 612 to JP 10114 and unbinds them 
from JP 10114 requires to perform the binding and unbinding operations. Figure 453 shows a Virtual 
Processor 612. The area of I^EM 10112 belonging to a Virtual Processor 612 is Virtual processor 612's 
Virtual Processor State Block (VPSB) 614. Each Virtual Processor 612 In a CS 10110 has a VPSB 614. 
Together, the VPSBs 614 make up VPSB Array 45301. Within the Virtual Processor management system, 

65 each Virtual Processor 612 is knovim by its VP Number 45304, which is the Index of the Virtual Processor 
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612*5 VPSB 614 in VPSB Array 45301. Virtual Processors 612 are managed by means of lists contained in 
Micro VP Lists (MVPL) 45309. Each Virtual processor 612 has an Entiy (MVPLE) 45321 In MVPL 45309, and 
as Virtual Processor 612 changes state, >nrtu8l processor management microcode moves it from one list to 
another in MVPL 45^)9. 
^ VPSB 614 contains two lands of information: 

information from Process Object 901 belonging to Process 610 which Is bound to VPSB 614's Virtual 
Processor 612, and information used by the Vlnual Processor Management System to manage Virtual 
Processor 612. The most important information from Process Object 901 is the Allowing: 

— Process 610's principal and process UIDs 40401. 

— AONs 41304 for Process 610's Stack Objects 44703. <VPSB 614 uses AONs 41304 because KOS 
guarantees that AONs 41304 belonging to Stack Objects 44703 will not change as long as a Process 610 
is bound to a Virtual Processor 612.) 

Gfven AON 41304 of Process 610's SS object 10336, ttie Virtual Processor Management System can 
locate thatportion of Process 610's state which is moved into registers belonging to JP 1 01 14 when process 
61p's Virtual Processor 612 is bound to JP 101 14. Similarly, when Virtual Processor 612 is unbound from JP 
10114, the virtual processor management system can move the contents of JP 10114 registers into the 
proper location In SS Object 10336. 

a. Virtual Processor Managment (Fig. 453) 

EOS can perform six operations on Virtual Processors 612: 

— Request VP allows EOS to request a Virtual Processor 612 from KOS. 

— Release VP allows EOS to retum a Virtual Processor 612 to KOS. 

— Bind binds a Process 610 to a Virtual Processor 612. 

— Unbind unbinds a process 610 from a Virtual Processor 612. 

25 — Run allows KOS to bind Process eiO^s Virtual Processor 612 to JP 101 14. 

— Stop prevents KOS from tending process 610's Virtual Processor 612 to JP 10114. 

As can be seen from the above list of operations^ EOS has no direct influence over the actual binding of 
a Virtual Processor 612 to JP 101 14. This operation is performed by a component of KOS microcode called 
the Dispatcher. Dispatcher microcode is executed whatever one of four things happens: 
30 — Process 610 whose Virtual Pr6oessor612 is currently bound to JP 101 14 executes an Await Operation. 

— Process 610 whose Virtual Processor 612 Is currendy bound to JP 10114 executes Bn Advance 
Operation which satisfies an Await Entry 44«)1 for some other Process 610. 

— Either Interval Timer 25410 or Egg Timer 25412 overflows, causing an Event Signal which invtrfees 
Dispatcher microcode. 

3$ — lOJP Bus 10132 is activated, causing an Event Signal whidi invokes Dispatcher microcode. lOS 101 16 
activates lOJP bus 10132 when it toads data into MEM 10112 for JP 10114. 

When Dispatcher microcode is Invoked by one of these events. It examines ftsts in MVPL 45309 to 
determine which Virtual Processor 612 is to run next For the purposes of the present discussion, only two 
lists are important: the running list and the eligible list In the preset embodiment, the running list, headed 

40 by Running List Head 45321, contains only a single MVPLE 45321, that representing Virtual Processor 61 2 
currently bound to JP 101 14. In embodiments with multiple JPs 101 14, the running list may have more than 
one MVPLE 45321. The eligible list, headed by Eligible Ust Head 45313, contains MVPLEs 45321 
representing those Virtual Processors 612 which may be tx>und to JP 101 14. MVPLEs 45321 on the eligible 
list are ordered by pnorities assigned Processes 610 by EOS. Whenever KOS Dispatcher microcode is 

395 invoked. It compares the priority of Process 610 whose Virtual Processor 612's MVPLE 45321 is on the 
running list with the priority of Process 610 whose Virtual Processor 612's MVPL£ 45321 is at the head of 
the eligible list If the latter Process 610 has a higher priority, KOS Dispatcher microcode places MVPLE 
45321 belonging to the former Process 610's Virtual Processor 612 on the eligible list and MVPLE 45321 
belonging to the latter Process 610's Virtual Processor 612 onto the running list Dispatcher microcode then 

50 sv/aps Processes 610 by moving state in JP 10114 belonging to the former Process 610 onto the former 
Process 610's SS object 1 0336 and moving JP 1 01 14 state belonging to the latter Process 610 from the latter 
Process 610's SS object 10336 into JP 10114. 

b. Virtual Proctors 612 and Synrfironization (fig. 454) 

S5 When a synchronization operation is performed on a Process 610, one of the consequences of the 

operation is a synchronization operation on a Virtual Processor 612. For example, an Advance Operation 
which satisfies an Await Entry 44804 for a Pr(x:ess 610 causes an Advance Operation which satisfies a 
second Await Entry 44804 for Process 610's Virtual Processor 612. Similarly, a synchronization operation 
performed on a Virtual Processor 612 may have a synchronization operation on Virtual Processor 612's 

$0 Process 610 as a consequence. For example, if a Virtual Processor 612 performs an operation involving file 
I/O. Virtual Processor 612'$ Process 610 must await the completion of the I/O operation. 

Rgure 454 illustrates the means by which process level synchronization operations result in virtual 
processor-level synchronization operations and vice-versa. The discussion first describes the components 
which transmit process-level synchronization operations to Virtual Proc^sors 612 and the manner in which 

es these components operate Then it describes the compor^nts which transmit virtual processor-level 
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synchronization operations to Processes 610 and the operation of these components. 

The first set of components is made up of VPSBA 45301 and VPAT 45401 . VPSBA 45301 is shown here 
with two VPSBs 614: one belonging to a Virtual Processor 612 bound to a user Process 610 and one 
belonging to a Virtual Processor 612 bound to the KOS Process Manager process 610. VPAT 45401 is a 

* virtual processor-level table of Await Entries 44804. Each Await Entry 44804 is contained in a VPAT Entry 
<VPA"re) 45403. Each Virtual Processor 61 2 bound to a Process 610 has a VPAT Chunk 45402 of four VPATEs 
45403 in VPAT 45401 , and can thus await up to four Event Counters 44801 at any given time. The location of 
a Virtual processor 6 12's VPAT Chunk 45402 is kept in Virtual Processor 612's VPSB 614. When an Advance 
Operation satisfies any of the Awaft Entries 44804 belonging to a Virtual Processor 612, all In Virtual 
Processor 612's VAT Chunk 45402's Await Entries 44804 are deleted. As In PET 44705, VPATES 45403 
containing Await Entries 44804 which are awaiting a given Event Counter 44801 are linked together in a list. 

VPATEs 45403 for Virtual Processors 61 2 bound to user Processes 610 may contain Await Entries 44804 
for user Process 610's Private Event Counter 45405. Private Event Counter 45405 Is contained In Process 
610's Process Object 301. tt is advanced each time an Await Entry 44804 in a PETE 44909 on a PET List 
belonging to Process 610 is satisfied. 

The components operate as follows: When KOS performs an Await Operation on Process 610, it makes 
Avtfait Entries 44804 In both PET 44705 and VPAT 45401 and puts Process 61 0's VP 61 2 on the suspended list 
in MVPL 45309. As previously described^ an Awaft Entry 44804 in PET 44705 awaits an Event Counter 44801 
specified in the Await Operation which created Await Entry 44804. Await Entry 44804 in VPAT 45401 awaits 

^ Process 610's Private Event Counter 45405. Each time an Await Entry 44804 belonging to Process 61 0 in PET 
44705 is satisfied. Process 610's Private Event Counter 45405 is advanced. The advance of Private Event 
Counter 45405 satisfies Await Entry 44801 for Process 610's Virtual processor 612 In VPAT 45401, and 
consequently, KOS deletes Virtual Processor 612's VPATEs 45403 and moves Virtual Processor 612's 
MVPLE 45321 in MVPL 45309 from the suspended list to the eligible list 

^ The components which allow a Virtual Processor 612 to transmit a synchroniza^on operation to a 

prooess 610 are the following: Outward Signals Object (OSO) 45409, Multiplexed Outward Signals Event 
Counter 45407, and PET 44705. OSO 45409 contains Event Counters 44801 which KOS FU 10120 microcode 
' advances when K perfoms operations which user Processes 61 0 are awaiting. Event Counters 44801 In OSO 
45409 are awaited by Await Entries 44804 in P^ 447(^ Each time KOS FU 10120 microcode advances an 

30 Event Counter 44801 in OSO it also advances Multiplexed Outward Signals Event Counter 45407. It 
is awaited by an Awaft Entry 44804 in VPAT 45401 belonging to Virtual Processor 612 bound to KOS 
Prooess Manager Process 610. When Virtual Processor 62 bound to KOS P rocess Manager Process 610 is 
again bound to JP 10114. KOS Process Manager Process 610 examines all PETEs 44809 belonging to the 
EventCounters 44801 inOSO45423.lfan8dvanceofanEv8ntCounter44801 inOSO44801 satisfied a PETE 

^ 44909 Process 610, that Process 610*6 Private Event Counter 45405 is advanced as previously described, 
and Process 610 may again execute. 

A user I/O operation Illustrates how the components work logger. Each user I/O channel has an Event 
Counter 44801 In OSO 45409. When a Process 610 performs a user VO operation on a channel, the EOS 1^0 
routine establish an Await Entry 44804 In the PET 44705 list belonging to Process 610 for the channel's 

« Event Counter 44801 in OSO 45409. When the I/O operation is complete, lOS 10116 places a message to JP 
101 14 in an area of MEM 1 01 12 and activates tOJP Bus 10132. The acthmtion of lOJP Bus 10132 causes an 
Event Signal which invokes KOS microcode. The microcode examines the message from lOS 10116 to 
determine which channel is Involved, and then advances Event Counter 44801 for that channel in OSO 
45409 and Multiplexed Outward Signals Event Counter 45407. The latter advance satisfies an Await Entry 

^ 44804 for Process Manager Process 610's Virtual Processor 612 In VPAT 45401, and Process Manager 
Process 610 begins executing. Process Manager Process 610 ©camines OSO 45409 to determine which 
Event Counters 44801 in OSO 45409 have been advanced since the last time process manager Process 610 
executed, and when it finds such an Event Counter 44801, it examines the Event Counter Chain in PET 
44705 for that Event Counter 44«)1 . If it finds that the advance satisfied any Await Entries 44804 in the Event 
. so Coumer Chain, It advances Private Event Coumer 45405 belonging to Process 610 specified In Await Entry 
44804. thereby causing that Process 610 to resume execution as previously described. 

F. Process 610 Stack Manipulation 

This section of the speciftcation for CS 10110 describes the manner in v^ich Process 610's MAS 502 

ss and SS 504 are manipulated. As previously mentioned, in CS 101 10, a Process 610's MAS 502 and SS 504 
are contained in several objects. In the present embodiment there are five objects, one for each domain's 
portion of the Macro Stack (MAS) (MAS Objects 10328 through 10324) and one for the Secure Stack (SS) 
(SS Object 10336). In other embodiments, a Process 610's MAS 502 may contain objects for user-defined 
domains as well. Though a Process 61 0's MAS 502 and SS 504 are contained in many objects, they function 

60 as a single logical stack. The division into several objects is a consequence of two things: the domain 
component of the protection system, which requires that an object referenced by a Procedure 602 have 
Procedure 602's domain of execution, and the need for a location inaccessible to user programs for 
micromachine state and state which may be manipulated only by KOS. 
Stack manipulation takes place under the following circumstances: 

fis — When a procedure 602 is invoked or a Return SIN is executed. Procedure 602 Invocations are 
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performed by means of a Call SIN. Call causes a transfer of control to the first SIN in the invoked 
Procedure 602 and the Return S{N causes a transfer of control back to the SIN in the imroking Procedure 
602 %vhich follows the Call SIN. 

— When a non-tocal Go To SIN is executed. The non-local Go To causes a transfer of control to an 
arbitrary position in some Procedure 602 which was previousiy invoked by Process 610 and whose 
invocation has not yet ended. 

— When a condition s rises, i.e.. an execution of a statement jn a program puts the executive Process 610 
into a state which require the execution of a previously established Handler Procedure 602. 

— When a Process 610 Is interrupted, i.e., when an Interrupt Entry 45718 for Process 610 is satisfied. 
Most of the ntechanisms involved in stack manipulation are used in Call and Return; these operations 

are therefore dealt with in detail and the other operations only as they differ from Call and Return. The 
discussion first imroduces Call and Return, then explains the stacks in detail, and finally analyzes Call and 
Return and the other operations in detail. 

1..lmroduction to Call and Return 

As a Process 610 executes a program, it executes Call and Return SINs. A Call SIN begins an invocation 
of a procedure 602, and a Retum SIN ends the invocation. Generally speaking, a Call SIN does the 
fot lowing: 

— It saves the state of Process 61 Cs execution of Procedure 602 which contains the Call SIN. Included in 
this state is the information required to continue Procedure 602*8 execution after the Call SIN is 
finished. This portion of the state is termed calling Procedure 602's Macrostat& 

— It creates the state which Process 610 requires to begin execution called Procedure 602. 

— It transfers control to the first SIN in the called Pra^dure 602's code. 

The f^m SIN does the opposite: it releases the state of called Procedure 602, restores the saved state 
of calling Procedure 602. and transfers control to the SIN in the calPing Procedure 602 following ihe Call SIN. 
An invocation of a Procedure 602 lasts from the execution of the Call SIN which transfers oontrol to the 
Procedure 602 to the execution of the Retum SIN which transfers oontrol back to Procedure 602 which 
contained the Call SIN. The state t)elonging to a given invocation of a Procedure 602 by a Process 610 is 
cail^J Procedure 602's invocation state. 

While Calls and Returr^ may be imptemented in many different feshtons, it is advantageous to 
implement them using stacks. When a Call creates Invocation state for a Procedure 602, that Invocation 
state IS added to the top of Process 610's stack. The area of a slack which contains the invocation state of a 
Procedure 602 is called a frama Since a called Procedure 602 may call another procedure 602, and that 
another, a stack may have any number of frames, each frame containing the invocation state resulting from 
the invocation of a Procedure 602 by Process 610, and each frame lasting as long as the invocation it 
represents. When raited Procedure 602 retums to Its caller« the frame upon whidi it executes is released 
and the caller resumes execution on its frame. Procedure 602 being currently executed fay a Process 610 
thus always mns on the top frame of Process 610's MAS 502. 

Calls and Retums In CS 10110 behave logically like those in other computer systems using stacks to 
preserve process 610 state. When a Process 610 executes a Call SIN, the SIN saves as l^rostate the 
current values of the ABP^, the location of the SIN at which the execution of calling Procedure 602 is to 
continue, and information such as a pointer to calling Procedure 602's Name Table 10350 and UID 40401 
belonging to the S-interpreter object which contains the S-interpreter for Procedure 602*8 Slanguage. The 
Call SIN tiien creates a stack frane for called Procedure 602, obtains tiie proper ABP values, the tocation of 
called Procedure ^2^$ Nante Table 10350 and UID 40401 belonging to its &4nterpreter object and begins 
executing newly-invoked Procedure 602 on the newly-created stack frame. The Retum SIN deletes the stack 
frame obtains the ABP values and name interpreter information from the Macrostate saved during the Call 
SIN and then transfers control to the SIN at which execution of calllrig Procedure 602 is to continue. 

However the manner in which Call and Retum are implemented is deeply affected by CS 10110's 
Access Control System Broadly speaking there are two classes of Calls and f^ms in CS O110: those 
which are mediated by KOS and those which are not In the following discussion, the former dass of Calls 
and Retums are termed Mediated Calls and Retums, and the latter are called Neighborhood Calls and 
Retums. Most Calls and Retums executed by CS 10110 are Neighborhood Calls and Returns; Mediated 
Calls and Retums are typically executed when a user procedure 602 calls EOS Procedures 602 and these in 
turn call KOS Procedures 602. The Mediated Call makes CS 10110 facilities available to user Processes 610 
while protecting these CS 10110 facilities from misuse and therefore generally serves the same purpose as 
system calls in the present art As will be seen in the ensuing discussion, Mediated Call requires more CS 
10110 overhead than Neighborhood Call but the extra overhead is less than that generally required by 
system calls in the present art 

Mediated Calls and Retums involve S-interpreter, Namespace, and KOS mioxjcode. S-interpreter and 
Namespace microcode interpret the Names involved in the call and only modifies those portions of 
Macrostate accessible to the S-interpreter. The remaining Macrostate is modified by KOS microroutines 
invoked in the course of the Call SIN. A Mediated Call may be made to any Procedure 602 contained in an 
object to which Process 610's subject has Execute Access at the time the invocation occurs. Mediated Calls 
and Retums must be made in the following situations: 
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— When called Procedure 602 has a different Procedure Environment Descriptor (PED) 30303 from that 
used by calling Procedure 602, Such Calls are termed Cross-PED Calls. 

— When called Procedure 602 Is in a different Procedure Object 608 from catling Procedure 602. Such 
Calls are termed Cross-Procedure Object Calls. 

5 — When called Procedure 602's Procedure Object 608 has a different Domain of Execution (DOE) Attribute 
from that of calling Procedure 602's Procedure Object 608, and therefore must place its Invocation 
State on a different MAS object from that used by calling Procedure 602. Such Calls are termed Cross- 
Domain Calls. 

In all of the above Calls, the information required to complete the Call is not available to the S- 
70 Interpreter and consequently, KOS mediation is required to complete the Call. Neighborhood Calls and 
Returns only modify two components of Macrostate: the pointer to the current SIN and the FP ABP. Both of 
these components are available to the S-interpreter as long as called Procedure 602 has the same PED 
30303 i»e., uses the same NameTabe 10350 and S-lnlerpreter or the calling Procedure 602 and has Names 
wi^ the same syllable size as calling Procedure 602. The Call and Return SINs are specific to each S- 
7S language, but they resemWe each other In tfieir genera! behavior. The following discussion will deal 
exclusively with this general behavior and will concentrate on Mediated Calls and Returns. The discussion 
first describes MAS 502 and SS 504 belonging to a Process 610 and those parts of Procedure Object 608 
involved in Calls and Returns, and then describes the Implementation of Calls and Returns. 

20 2. Macro Stadcs (MAS) 502 (Fig. 467) 

Rgure 467 gives an overview of an object belonging to a Process 610's MAS 502. The description of 
this Hgure will be followed by descriptions of other Figures containing detailed representations of portions 
of MAS objects. 

At a minimum MAS Object 46703 comprises KOS MAS Header 10410 together with Unused Storage 
25 46727 reserved for the other elements compHsing MAS Object 46703. If Process 610 has not yet returned 
from an invocation of a Procedure 6Q2 contained In a Procedure Object 608 whose DOE Is that required for 
access to MAS Object 46703. MAS object 46703 further comprises a Stack Base 46703 and at least one MAS 
Frame 46709. 

Each MAS Frame 46709 represents one mediated Invocation of a procedure 602 contained in a 
30 Procedure Objeoe Stm wi^ the DOE attribute required by MAS 46703, and may in addition represent 
neighborhood invocations of Procedures 602 which share that Procedure 602's Procechire Object 60& The 
topmost MAS Frame 46709 represents the most recent group of invocaUons of Procedures 602 with the 
DOE attribute required by MAS Object 46703 and the bottom MAS Frame 46709 the earliest group of 
invocations from which Process 610 has not yet returned. Frames for invocafions of Procedures 602 with 
35 other domains of execution are contained in other MAS Objects 46703. As will be explained in detail below 
MAS Frames 46709 m .different iVIAS objects 46703 are linlced by pointers. 

MAS Domain Stack Base 46703 has two main parts: KOS MAS Header 10410 which contains 
information used by KOS microcode which manipulates MAS Oi^ect 46703, and Perdomain Information 
46707, which contains Information about 46703's domain and static information, 1,e., information which 
40 lasts longer than an invocation used by Procedures 602 with MAS Frames 46709 on MAS Obiect 46703. 
MAS Frame 467(» also has two main parts, a KOS Frame Header 10414 which contains infomnation used by 
KOS to manipulate Frame 46709 and S-interpreter Portion 46713 which contains Infomnatlon available to 
the S>interpreter when it executes the group of Procedures 602 whose invocations are r^esented by 
Frame 46709. 

45 When making Calls and Returns, the Snnterpreter and KOS microcode use a gnoup of pointers to 
locations in MAS Object 46703. These pointers comprise the following: 

— MAS Object UID 46715 the UID 40401 of AS Object 46703. 

— First Frame Offset (FFO) 46719 which locates the beginning of KOS Frame Header 10414 belonging to 
the first IVIAS Frame 46709 in MAS Object 46703, 

so — Frame Header Pointer (FHP) 46702 which locates the beginning of the topmost KOS Frame Header 
10414 in MAS Object 46703. 

— Stack Top Offset (STO) 46704 a 32-bit offset from Stack UID 4671 5 which marics the first bit in Unused 
Storage 46727, 

As will be seen presently all of these pointers are contained in fields in KOS MAS Header 46705. 

5S 

a.a. MAS Base 10410 <Rg. 468) 
Figure 468 is a detailed representation of MAS Domain Stack Base 10410 Turning first to the detailed 
representation of KOS MAS Header 46705 contained therein, there are the following fields: 

— Format Information Held 46801 containing infonmation about the format of KOS MAS Header 46705, 
^ _ Flags Reld 46803. Of these flags, only one is of Interest to the present discussion: Domain Active Rag 

46804. This flag is set to TRUE when Process 610 to which MAS Object 46703 belongs is executing the 
Invocation of Procedure 602 whose invocation record makes up the topmost iVlAS Frame 46709 
contained in MAS Object 46703 to which KOS MAS Header 46705 belongs. 

— PFO Reld 46805: All MAS Headers 46705 and Frame Headers 46709 have fields containing offsets 
£S locating the previous and following headere in MAS Object 46703. In a Stack Header 46705 there is no 
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previous header and this field is set to 0. 

— FFO Feld 468C»: The field locating the following header In a Stack Header 46705 this field contains FFO 
46719 since the next header is the first Frame Header in MAS Object 46703. 

— STO Field 46807: the field containing STO offset 46704. 

— Process ID Reld 46809; UID 40401 belonging to Process Object 901 for Process 610 to which MAS 
Object 46703 belongs. 

— Domain Environment Information pointer Reld 46811: The pointer contained In the field locates an 
area which contains domain-specific information. In the present embodiment, the area is part of MAS 
Stadc Base 10410; however, in other embodiments, it may be comained in a separate object 

— Signaller Pointer Reld 46813: The pointer contained in the field locates a Procedure 602 which KOS 
invoices when a Process 610's execution causes a condition to arise while it is executing in the domain 
to which MAS object 46703 belongs. 

— AAT Pointer Field 30211: The pointer in Field 30211 locates AAT 30201 for MAS Object 46703. AAT 
30201 is described in detail in Chapter 3. 

— Frame Label Sequencer Field 46819: This field contains a Sequencer 45102. Sequencer 45102 is used to 
generate labels used to locate MAS Frames 46709 when a non-local GOTO is executed. 

Turning now to the detailed representation of Domain Environment Information 46821 located by ' 
Domain Environment Information Pointer Field 46811 there are the following fi^ds: 

— KOS Format Information Field 46823. 

— Flags Reld 46825 containing the following flags: 

— Pending Interrupt Rag 46827, set to TRUE when Process 610 has an interrupt pending for the 
domain to which MAS Object 46703 belongs. 

— Domain Dead Flag 46829, set to TRUE when Process 610 can no longer execute Procedures 602 
with domains of execution equal to that to which MAS Object 46703 belongs. 

— Invoke Verify on Entry Rag 46833 and Invoke Verily on Exit Rag 46835. The former flag Is set to 
TRUE wh^ KOS is to invoke a Procedure 602 which checks the domain's data bases before a 
Procedure 602 is allowed to execute on the domain's MAS Object 46703; the latter Is set to TBUE 
when KOS is to invoke such a Procedure 602 on exit from a Procedure 602 with the domain as its 
[X)E. 

— Default Handler Non-null Rag 46835 is setto TRUE when there is a de^tt clean-up handler for the 
domain. Oeannip handlers are dest^ibed later. 

— Interrupt Mask Reld 46839 determines what interrupts set for Process 610 in MAS object 46703'$ 
domain will be honored. 

— Domain UID Reld 46841 contains UID 40401 for the domain to which MAS Object 46703 belongs. 

— Relds 46843 through 4684S are pointers to Procedures 602 or tables of pointeis to Procedures 602. 
The Procedures 602 so located handle situations which arise as i^^s 502 are manipulated. The 
use of these fields will become dear as the operations which require their use are explained. 

b.b. Per-domatn-Osta Area 46853 (Rg. 468( 

Per-domain Data Area 46853 contains data which cannot be kept in MAS Frames 46709 belonging to 
invocations of Procedures 602 executing in MAS Object 46703's domain, but which must foe available to 
these invocations Per-Domafn Data Area 46853 has two components: Storage Area 46854 and AAT 30201. 
Storage Area 46854 contains static data used by Procedures 602 with invocations on MAS Object 46703 and 
data used by S-lnterpreiers wrtilch are used by such procedures 602. Associated Address Table (AAT) 30201 
is used to locate data in Storage Area 46854. A detailed discussion of AAT :M201 is contained in Chapter 3. 

Two kinds of data is stored In Storage Area 46854: static data and S-interpreter data. 

Static data is stored in Static Data Block 46863. Static Data Block 46863 comprises two parts: Linkage 
Pointers 46865 and Static Data Storage 46867 Linkage Poimers 46865 are pointers to static data not 
comained in Static Data Storage 46867 for example, data which lasts longer than Process 610 and pointers 
to External Procedures 602 which the Procedure 602 to which Static Data Storage 46867 lielongs invokes. 
Static Data Storage 46867 contains storage for static data used by the Procedure 602 which does not last 
longer than Process 610 executing the Procedure 602. 

S-interpreter data Is data required by S-lnterpreters ised by Procedures 602 executing on MAS object 
46703. 

The S-interpreter data is stored in S-interpreter Environment Block (SEB) 4®64 which, like Static Data 
Block 46864 is located via AAT ^201 : The contents of SEB 46864 depend on the S-interpreter. 

ac MAS Frame 46709 Detail {fig, 469) 
Figure 469 represents a typical frame in MAS Object 46703. Each MAS Frame 46709 contains a 
Mediated Frame 46947 produced by a Mediated Call of a Procedure 602 contained In a Procedure Object 
608 whose DOE attribute is the one required for execution on MAS object 46703. Mediated Frame 46947 
may be followed by Neighborhood Frames 46945 produced by Neighborhood Calls of Procedures 602. 
Mediated Frame 46947 has two parts, a KOS Frame Header 10414 which is manipulated by KOS microcode, 
and an S-interpreter portion which is manipulated by Snnterpr^r and Namespace microcode. 
Neighborhood Frames 46945 have no KOS Frame Headers 10414. As will become dear upon closer 
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examination of Figure 469. Mediated Frames 46947 in the present embodiment contain no Macrostate, In 
the present embodiment, Macrostate for these frames is kept on SS Object 10336; however in other 
embodiments, Macrostale may be stored in Mediated Frames 46947. Neighborhood Frames 46945 contain 
those portions of the macrostate which may be manipulated by Neighborhood Call; the location of this 
^ macrostate depends on the Neighborhood Call SIN. 

Turning now to KOS Frame Header 10414. there are the following fields: 

— KOS Format Information Field 46901 containing information about MAS Frame 46709's format. 
Rags Field 46902. This field contains the following flags: 

— Result of Cross-domain Call Flag 46903. This Flag is TRUE if MAS Frame 46709 which precedes this 
w MAS Frame 46709 is in another MAS Object 46703. 

— Is Signaller Rag 46905. This flag is TRUE if this MAS Frame 46709 was created by the invocation of 
a Signaller Procedure 602. 

— Do Not Retum Flag 46907: This flag Is TRUE If Process 610 is not to return to the invocation for 
♦which this MAS Frame 46709 was created. 

IS ^ Flags 46909 through 46915 indicate viHiether various lists used in condition handling and non-local 
GOTOs are present in tfie MAS Frame 46709. 

— Previous Frame Offset Reld 46317. Next Frame Offeet Reid 46919. and Frame Top Offset Field 46921 
are offsets which gwe the location where Heacter 10414 for the previous MAS Frame 46709 in MAS 
Object 46703 begins, the location vi/here the header for the next MAS Frame 46709 In MAS Object 

20 46703 begins, and the location of the first bit beyond the top of MAS Frame 46709 respectively. 

— Relds 46923 through 46927 are offoets which locate lists In S-interpreter portion 46713 of Frame 46709. 
KOS establishes such Ifets to handle cortdltions and non-local GOTOs. Their use vwll be explained In 

. detail under those headings. 

— Fields 46929 and 46933 contain information al>out Procedure 602 whose Invocation Is represented by 
25 MAS Frame 46709. Reld 46929 contains the number of arguments required by procedure 602 and Reid 

46933 contains a resohrable pointer to Prooedura 602*8 PED 30303. Both these fields are used primarily 
for debugging. 

— Dynamic Back P<Mnter Reld 46931 contains a resolvabie pointer to the preceding MAS Frame 46709 
belonging to Process 610's MAS 502 when that MAS Frame 46709 Is contained in a different MAS 

30 Object 46703, In this case. Rag Reld 46903 is set to TRUE. When the preceding MAS Frame 46709 is 
contained in the same MAS object 46703 field 46931 contains a pointer with a null UID 40401 and Rag 
Reid 46S03 is set to FALSE. 

— Fiame Label Reld 469^ is for a Frame Label produced when a non4ocaI GOTO is established which 
transfers control to the invocation represented by MAS Frame 46709. The lab^ is generated by Frame 

35 Label Sequencer 46819 in KOS MAS Header 10410. 

S-interpreter Portion 46713 of MAS Frame 46709 compHses those portions of MAS Frame 46709 which 
are under contrt>l of the S-interpreter. S-interpreter Portion 4671 3 in turn comprises two main subdhrisions: 
those parts belonging to Mediated Frame 46947 and those belonging to Neighborhood Frames 4694S. 
The exact form of S-interpreter portion 46949 of KOS Frame 46947 and of S-lnterpreter Frames 46945 

40 depends on the Call SIN which cieated the frame in question. However alt Neighborhood Frames 46945 and 
S-interpreter portions 469^ of Mediated Frames 46947 have the same arrangements for storing Unlcage 
Pointers 10416 and local data in the frame. Linkage Pointers 10416 are pointers to the locations of actual 
arguments used in the invocation and Local Storage 10420 contains data which exists only during the 
invocation. In all Mediated Frames 46947 and Neighborhood Frames 46945. Linkage pointers 10416 

45 precede Local Storage 10420. Furthermore, when a Mediated Frame46947 or a Neighborhood Frame 46945 
IS the topmost frame of Process 610's MAS. i.e, when Process 610 is executing on that frame, the FP always 
points to the beginning of Local Storage 10420, and the beginning of Linkage Pointers 10416 Isalways.at a 
known displacement from FP. References to Linkage Pointers 10416 may therefore be expressed as 
negative offsets from FP, and references to Local Storage 10420 as positive offsets. 

$0 In addition, S-interpreter Portion 46713 may contain lists of infomnation used by KOS to execute non- 
local GOTOs and conditions, as well as S-interpreter frames for non-mediated calls. The lists of information 
used by KOS are contained in List Area 46943. The exact location of Ust Area 46943 is determined by the 
compiler which generates the SINs and Name Table for the Procedure 602 whose invocation is represented 
by Mediated Frame 46947, When Procedure 602's source text contains statements requiring storage in Ust 

55 Area 46943, the compiler generates SINs whltrfi place the required amount of storage in Local Storage 
10420. KOS routines then build lists In Area 46943, and place the offsets of the heads of the lists in Fields 
46923, 46925 or 46927, depending on the kind of list The lists and their uses are described In detail later. 



3. SS 504 IRg. 470) 

60 Rgure 470 presents an overview of SS 504 belonging to a Process 61 0. SS 504 is contained in SS Object 
10336. SS Object 10336 is manipulated only by KOS microcode routines. Neither Procedures 602 being 
executed by Process 610 nor Snnterpreter or Namespace microcode may access Information contained in 
SS Object 10336. 

SS Object 10336 comprises two main components, SS Base 47001 and SS Frames 47003. Turning first 
65 to the general structure of SS Frames 47003, each time a Process 610 executes a Mediated Call KOS 
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microcode creates a new SS Frame 47003 on SS Object 10336 bdonging to Process 610 and each time a 
Process 610 executes a Mediated Return, KOS microcode removes the current top SS Frame 47003 from SS 
Object 1033a There is thus one SS Frame 47003 on SS Object 10336 belonging to a process 610 for each 

mm mm mi on rroGiiH tin m 

SS Frames 47003 comprise two lands of frames: 

Ordinary Frames 10510 and Cross^tomain Frames 47039. Cross*domain Frames 47039 are created 
whenever Process 610 executes a Cross-domain Call; for all other Mediated Calls. Ordinary Frames 10510 
are created. Cross-domain Frames 47039 dwide SS Rames 47d03 into Groups 47037 of SS Frames 47003 
belonging to sequences of invocations in a single domain. The first SS Frame 47<»3 in a Group 47037 is a 
10 Cross-domain Frame 47039 for the invocation which entered the domain, and the remainder of the SS 
Frames 47003 are Ordinary Frames 1 051 0 for a sequence of Invocations in that domain. These groups of SS 
Frames 47003 correspond to groups of Mediated Frames 46947 in a «ngle MAS Object 46703. 

a.a. . SS Base 47001 (Rg. 471) 
IS SS Base 47001 comprises four main parts: SS Header 10512 Process Microstate 47017, Storage Area 
47033 for JP 10114 register contents, and Initialization Frame Header 470^ Secure Stack Header 1051? 
contains the following information: 

— Fields 47001 and 47009 contain flag and format information; the exact contents of these fields are 
unimportant to the present discussion. 

20 — Previous Frame Offset Value Field 4701 1 is a standard field en headers in SS Object 1 0336: here it is set 
to 0, since there is no previous frame. 

— Secure Stack Rrst Frame Offset Field 47013 contains the offset of the first SS Frame 47039 in SS object 
10336, i.e,. Initialization Frame Header 47035. 

— Proc^ UID field 47015 contains UID 40401 of Process 610 to which SS Object 10336 belongs. 

25 — Number of Cross Domain Frames Reld 4701 6 contains the number of Cross-domain Frames 47039 in 
SS Object 1033a 

Process Microstate 47017 contains infonmation used by KOS microcode when it executes Process 610 
to which SS Object 10336 belongs Fields 47019, 47021 and 47022 contain the offsets of locations in SS 
Object 10336. Field 47019 contains the value of SSTO the location of the first free bh in SS Object 10336; 

30 Held 47021 contains the value of SSFO, the location of the topmost frame In SS object 103^; Reld 47022 
finally contains the value of XDFO, the location of the topmost Cross-domain Frame 47039 in SS Otject 
10336. All of these locations are marked in Figure 470. 

Other fields of interest in Process Microstate 47017 comprise the following: Offsets in Storage Area 
field 47023 contains offsets of locations in Storage Area 47033 of SS Object 10336; Donrtain Number Reld 

35 47025 contains the domain number for the DOE of Procedure 602 currently being executed by Process 61 0. 
The relationship between domain UIDs and domain numtiers is explained in the discussion of domains. 
VPAT Offeet Reld 47027 contains the offset in VPAT 45401 of VPAT Chunk 45402 belonging to Virtual 
Processor 612 to which Process 610 is bound. Signal Poimer Field 47029 contains a resohred pointer to the 
Signaller (a Procedure 602 used in contiltion handling) belonging to the domain specified by Domain 

4Q Numt>er Reld 47025 and Trace Information Field 47031 contains a resoh^ed pointer to that domain's Trace 
TaJ]rfe described later. 

Storage Area for JP 10114 register Contents 47033 is used when a Virtual Processor 612 must be 
removed from JP 101 14. When this occurs, either because Virtual Processor 61 2 is unbound from JP 101 14, 
because CS 101 10 is being hailed, or because CS 101 10 has failed, the contents of JP 101 14 registers which 
45 contain information spedfic to Virtual Processor 612 are copied imo Storage Area 47033. When Virtual 
Processor 612 is returned to JP 10114, these register contents are loaded back into the JP 10114 registers 
from whence they came. Initialization Frame Header 47035, finally* is a dummy frame header vtrhlch is used 
in the creation of SS Object 10336. 

so b.b. SS Frames 47003 (Fig. 471) 

Commencing the discussion of SS Frames 47039 and 10510. figure 471 illustrates these structures in 
detail. Ordinary SS Frame 10510 cmiprises thres main divisions: Ordinary SS Frame Header 10514, 
Macrostate 10516 and Microstate 10520. Ordinary SS Frame Header 10514 comains information used by 
KOS microcode to manipulate Ordinary SS Frame 1051 0 to which Header 1<K14 belongs. Macrostate 1 051 6 

55 contains the values of the ABPs for the frame's mediated invocation and other Information required to 
resume execution of the invocation. Microstate 1(B20 contains micromachine state from FU 10120 and EU 
10122 registers. The amount of micromachine state depends on the circumstances; in the present 
embodiment some micromachine state Is saved on all Mediated Calls; furthermore, if a Process 610 
executes a microcode-to-software Call, the micromachine state that existed at *e time of the call is saved; 

go finally. Microstate 10520 belonging to the topmost SS Frame 47003 may contain information which was 
transferred from FU 10120 GRF registers 10354 or EU 10122 register and stock mechanism 10216 when 
their capacity was exceeded. For details about this portion of Microstate 10520 see the discussion of the FU 
10120 micromadiine in Chapter 2. The discussion of SS Object 10336 continues with details concerning SS 
Header 10514 and Macrostate 05163. 

65 
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a,a.a. Ordinary SS Frame Headers 10514 (Rg. 741) 
Relds of Interest in Ordinary Secure Stack Frame Header 10514 are the following: 

— Format Information 47103 which identifies the format of Header 10514. ^ ^ „ ^^^^^ . 

— Flags Held 471C© which contains one flag of interest In this discussion: Frame Type Hag 47107: m 
s Ordinary SS Frames 10510 this field is set to FALSE, 

— Offset Relcte 47109 through 47113: Reld 47109 contains the offset of the previous SS Frame 47039 or 
10510. Reld 47111 contains the offset of the following SS Frame 47039 or 10510. and Reld 47113 
contains the offset of the last SS Frame 47039 or 10510 preceding the next Crossdomain Frame 47039 

— Field 47117 contains the current domain number for the domain in which the mediated invocation 
represent SS Frame 47039 or 10510 is executing. 

— Reld 471 19 contains the offset of the preceding Cross-domain Frame 47039, 

— Reld 47121 contains offsets for important locations in Wllcrostate 10520. 

b.b.b. Detailed Structure of Macrostate 1051 6 (Fig. 471 ) 
These fields are of interest in Macrostate 10516; ^ . 

— Syllable Size Field 47125 contains the value of I.e., the size of the Names m the SiNs belonging to 
Procedure 602 which the invocation is executing. 

— End of Name Table Reld 47127 contains the location of the last Name in Name Table 10350 belonging 
to Procedure 602 which the invocation is executing. 

20 ^ Relds 47129 through 47143 are resoh/ed pointers to locations in Procedure Object 901 containmg 
Procedure 602 being executed by the invocation and resolved pointers to locations containing data 
being used by Procedure 602. Reld 47129 contains a pointer to Procedure 602's PED 30303; if 
Procedure 602 Is an External Procedure 602. Reld 47131 contains a pointer to Procedure 602's entry In 
Gates 10340; Reld 47135 contains the UlD-offset value of FP for the invocation; Field 47135 contains a 

25 pointer to SEB 46864 us^ by Procedure 602's S-interpreter. Reld 471 37 contains the UID-offfset value 
of SDP and Reld 47139 contains that of PBP. SIP Reld 47141 contains a pointer to Procedure 602's S- 
int^reter object and NTP, finally, is a pointer to Procedure 602's Name Table 10350. 

— Reld 47145 contains the PC for the SIN which is to be executed on retum from the nnediated Invocation 
to which SS Frame 47003 belongs. 

30 

ccc. Cross domain SS Frames 47039 (Rg. 471} 
Cross-domain SS Frames 47039 differ from Ordinary SS Frames 10510 in two respects: they have an 
additional component Cross-domain State 10513, and fields in Cross domain Frame Header 47157 have 
different meanings from Owse in Ordinary Frame Header 10514. 

SS Cross-domain State 10513 contains information which KOS Call microcode uses to venfy that a return 
to 8 Procedure 602 whose DOE dififers from that of Procedure 602 whose invocation has ended is returning 
to the $mper domain. Relds of Interest in Cross^lomain State 10513 include GOTO Tag 47155 used for non- 
local GOTOs which cross domains. Stack Top Pointer Value 47153, which gives the location of the first free 
bit in the new domain's MAS Object 46703 and Frame Header Pointer Value 47151, which contains the 

40 locsHon of the topmost Mediated Frame Header 467W in new MAS Object 46703. 

There are three fields In Cross-domain Frame Header 47157 which differ from those m Ordinary SS 
Frame Header 47101. These fields are Rag Reld 47107 which in Cross-domain Frame Header 471 57 always 
has the value TRUE, preceding Crossdomain Frame Offset Reld 47161, which contains the offset of 
preceding Cross-domain Frame 47039 in SS Object 10336 and Next Cross domain Frame Offiset Reld 47159. 

4S which contains the location of the next Cross-domain Frame 47039. These last two fields occupy the same 
locations as Relds 47111 and 47109 respectively in Ordinary SS Frame Header 10514. 

As wll be noted from the above descnption of SS Frames 47003. Secure Stack Ob^ct 10336 m the 
present embodiment contains three kincte of information: macrostate cross-domain state and microstate. 
In other embodiments, the information In SS object 10336 may be stored in separate stack structures, for 

so example, separate microstate and cross-domain stacks, or information presently stored in MAS Objects 
46703 may be stored in SS Object 10336, and vice-versa. 

4. Portion of Procedure Object 608 Relevant to Call and Return (Rg. 472) 

The information which Process 610 requires to construct new frames on its iVlAS Objects 46703 and SS 
55 Object 10336 and to transfer control to invoked Procedure 602 is contained in invoked Procedure 602's 
Procedure Object 608. Rgure 472 is an overview of Procedure Object 608 showing the information used in a 
Call. Rgure 472 expands information contained in Rgures 103 and 303; fields that appear in those Figures 
have the names and numbers used there. 

Beginning with Procedure Object Header 10336, this area contains two items of information used in 
60 Calls: an offset in Field 47201 giving the location of Argument Information Array 10352 in Procedure Object 
' 608 and a value in Reld 47203 specifying the number of gates in Procedure Object 608. Gates allow the 
invocation of External Procedures 602 that is. Procedures 602 which may be invoked by Procedures 602 
contained in other Procedure Objects 608. Procedure Object 608's gates are contained in External Entry 
Descriptor Area 10340. There are two kinds of gates: those for Procedures 602 contained in Procedure 
65. Object 608, and those for procedures 602 contained in other Procedure Objects 608, but callable >^a 
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Procedure Obje<^ 60a Gates for Procedures 602 contained in Procedure Object 608 are termed Local Gates 
47205, Local Gates 47205 contain Internal Entry Offset (lEO) Reld 47207 which contains the offset in 
Procedure Object 608 of Entry Descriptor 47227 for Procedure 602. H Procedure 602 is not contained In 
Procedure Object 472 its gate is a Link Gate 47206. Link Gates 47206 contain Binder Area Pointer (BAP) 
^ Relds 47208, A BAP Field 47208 contains the locations of an area in Binder Area 30323 which In turn 
contains a pointer to a Gate in another Procedure Object 608. The pointer in Binder Area 30323 may be 
either resolved or unresolved. If Procedure 602 is contained in that Procedure Object 608, the Gate is a Local 
Gate 47205; othenMse, it is another Link Gate 47206. 

Proc^ure Environment Descriptors (PEOS) 10348 contains PEDs 30303 for Procedures 602 contained 
in Procedure Object 608. Most of macrostate information for a Procedure 602 may be found In its PED 
30303. PED 30303 has already been described, but for ease of understanding^ its contents are reviewed 
here. 

— K Field 30305 contains the size of Procedure 602's Names. 

— Largest Name {LN) Reld 30307 contains the i 

Beginning wnth Procedure Object Header 10336, this area contains two items of information used in 
Calls: an Offset in Reld 47201 giving the location of Argument Information Array 10352 in Procedure Object 
608 and a value in Reld 47203 specifying the number of gates in Procedure Object 608. Gates allow the 
invocation of External Procedures 602, that is, Procedures 602 which may be Invoked by Procedures 602 
contained in other Procedure Objects 6nter to Static Data Block 46863. Thus, for that Invocation of 
^0 Procedure 602 on Invocation the SOP ABP Is derived via SDPP field 30313. 

— P6P Field 3031 5 is the pointer from which the current PC is calculated. When Procedure 602 is invoked, 
this value becomes the PBP ABP. 

— S-interpreter Environment Prototype Pointer (SEPPl Reld 30316 contains the location of SEB Prototype 
Reld 30317. When Procedure 602 is invoked, Reld 30316 locates SEB 46864 via AAT ^01 in the same 

25 manner as SDPP field 30313 locates the Invocation's static data. 

A Procedure ^2's PED 30303 may be located from its Internal Entry Descriptor 47227. A PED 30303 
may be shared by several Procedures 602. Of course in this case, the values contained in shared PED 30303 
are the same for all Procedures 602 sharing it As will be explained in detail later in the present 
embodiment, if a calling Procedure 602 does rwt share a PED 30303 with called Procedure ^2 tfie Call nuist 

30 be mediated. A calling Procedure 602 may make a Neighborhood Call only to Procedures 602 with which it 
shares a PED 30303. 

The next portion of Procedure Object 608 which is of interest is Internal Entry l3escriptors 10342. Each 
Procedure 602 contained in Procedure Object 608 has an Entry Descriptor 47227. Entry Descriptor 47227 
contains four fields of interest: 
35 — PBP Ofliset Reld 47229 contains the offset from PBP at which the first SIN in Procedure ^'s code is 

located. 

— Rags Reld 47230 contains flags which iare ehedced when Procedure 602 is invoked. Four flags are of 
interest: 

— Argument Information Array Present Rag 47235 which is set to ITtUE if Procedure 602 has entries 
40 tn Argument Information Array 10352. 

— SEB Rag 47237 is set to TRUE if SEPP 47225 is non-nulL Le.^ if Procedure 602 has a SEB 46864 for 
its S-interpreter. 

— Do Not Check Access Flag 47239 is set to TRUE if KOS Call microcode Is not to perform protection 
checking on the actual arguments used to invoke Procedure 602. 

45 ^ PED Offset Reld 47231 contains the offset of Procedure 6Q2's PED 30303 from the beginning of 
Procedure Object 608. 

— Heme Size Reld 47233 contains the initial size of the Lxx:al Storage Portion 10420 of MAS Frame 
46709 for an invocation of procedure K)2. 

Other areas of interest for Calls are SEB Prototype Ar^a 47241, Static Data Area Prototype 30317, 
Binder Area 30323 and Argument Information Array 10352. SEB Prototype type Area 47241 and Static Data 
Area Prototype 30315 contain information used to create an SEB 46864 and Static Data Block 4^63 
respectively for Procedure 602. These areas are created on a per-MAS Object 46703 basis. The first time 
that a Process 610 executes a Procedure 602 in a domain, SEB 46864 and Static Data Block 46863 required 
for Procedure 602 are created either in MAS Object 46703 belonging to the domain or In another ot)jact 
55 acces^ble from MAS Object 46703. SEB 46864 and Static Data Blodc 46863 then remain as long as MAS 
• Object 46703 exists. 

Static Data Prototype 30317 contains two kinds of information: Static Data Links 30319 and Static Data 
Initialization Information 30321 Static Data Links 30319 contain locations in Binder Area 30323. which in 
turn contains pointers which may be resolved to yield the locations of data or External Procedures 602. 
€0 When a Static Data Block 46863 is created for a Procedure 602, the information In Binder Area 30323 is used 
to create Linkage Pointers 46865. Static Data Initialization Information 30321 contains information required 
to create and initialize static data in Static Data Storage 46857. 

As mentioned in the discussions of Link Gates 47206 and Static Data Unks 30319 Binder Area 30323 
contains pointers which may be resoh^ed as described in Chapter 3 to yield locations of data and External 
£5 Procedures ^2. 
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Argument Information Array (AIA) 10352 contains information used by KOS Call microcode to check 
whether the subject which is invoicing Procedure 602 has access to the actual arguments used in the 
invocation which allows the uses made of the arguments In Procedure 602. This so-called 'Trojan horse 
check" is necessary because a Call may change the domain component of a subject Thus, a subject which 

5 Is lacking access of a specific kind to a data item could gain that access by passing the data item as an 
argument to a Procedure 602 whose DOE gives it access rights that the calling subject itself lacks. 

Each Local Gate 4720& In Procedure Object 608 has an eiement in AIA 10352. Each of these Argument 
Information Anray Elements (AlAEs) 60845 has fields indicating the following: 

The minimum number of arguments required to invoke Procedure 602 to which Lxica! Gate 47205 
10 belongs. In Held 47247. 

The maximum number of arguments which may be used to invoke Procedure 602 in Field 47249. 
^ The access rights that the invoking subject must have to tl^ actual arguments In order to Invoke 
Procedure 602 in Field 47251. 

Rekr47251 is itself an array which spedl^es the kinds of access that the Invoking subject must have to 
* the actual arguments It uses to invoke Procedure 602. Each fonmal argument for Procedure 602 has an 
Access Mode Array Entry (AMAE) 47^. The order of the AMAEs 47255 corresponds to the order of 
Procedure 602*8 formal arguments. The first formal argument has the first AMAE 47255, the second the 
second, and so forth. An AMAE 47253 is four bits long. There are two fonms of AMAE 47253: Primitive 
Access Form 47255 and Extended Access Form 47^. In the former form, the leftmost bit is set to 0. The 
20 three remaining bits specify read, write, and execute access. If a bit is on, the subject performing the 
invocation must have that kind of primitive access to the oi^ect containing the data item used as an actual 
for the fonnnai argument corresponding to that AMAE 47253. In the Extended Access Form 47257, the 
leftmost bit is set to 1 and the remaining bits are defined to represent extended access required for 
Procedure 602. The definition of these bits varies from Procedure 602 to Procedure 602. 

25 

5. Execution of Mediated Calls 

Having described the portions of MAS Object 46^, SS Object 10336. and Procedure Object 608 which 
are invoked in Calls, the dtscu^on tums to the description of the Mediated Call Operation. Rrst, there is 
presented an overview of the Mediated Call SSN and then the Implementation of Mediated Calls in the 
30 present embodiment Is (fiscussed, beginning with a simple Mwiiated Call and continuing with Cn>ss- 
Procedure Object Calls and Cross Domain Calls. The discussion closes with a description of software^o- 
microcode Calls. 

a. 8. Mediated Call SINs 

35 While the exact form of a Mediated Call SIN is S-language spedrflc, all Mediated Call SINs must conts^n 
four items of information: 

— The SOP for the op^-ation, 

— A Name that evaluates to a pointer to the Procedure ^2 to be invoked by the SIN. 

— A literal (constent) specifying the number of actual arguments used In the invocation. 

4D — A list of Names which evaluate to pointers to the actual arguments used in tiie invocation. 

If Procedure 602 requires no arguments, the iit^al will be 0 and the list of Names representing tiie 
actual arguments will be empty. 

in the present embodiment Mediated Call and Return SINs are used whenever called Procedure 602 
has a different PED 30^ from calling Procedure 602. In tills case, the Call must save and recateulate 
49 macrostate other than FP and PC, and mediation by KOS Call microcode is required. The manner in which 
KOS Call microcode mediates the Call depends on whether the Call Is a simple Mediated Call a Cross- 
procedure Object CbWm or a Cross-Domain Call. 

b. b. Simple Mediated Calls (Rg. 270, 468, 469, 470, 471 , 472) 

so When the Mediated Call SIN is executed, S-lnterpreter microcode first evaluates the Name which 
represents the location of the called Procedure 602. The Name may evaluate to a pointer to a Gate 47205 or 
4707 in another Procedure Object 608 or to a pointer to an Entry Descriptor 47227 in the present Procedure 
Obje<a 608. When the Name has been evaluated, S-lnterpreter Call microcode invokes KOS Call microcode, 
using the evaluated Nanne as an argument. This microcode first fills in Macrostate Relds 10516, left empty 

^ until now, in the current invocation's SS Frame 47003. The microcode obtains the values for these fields 
from registers In FU 10120 where they are maintained while Virtual Processor 612 of Process 610 which is 
executing the Mediated Call Is bound to JP 10114. 

The next step to determine whether the pointer which KOS Call microcode received from S-interpreter 
Call microcode is a pointer to an External Procedure. To make this determination, KOS Call microcode 

GO compares the pointer's AON 41304 with that of Procedure Object 608 for Procedure 602 making the Call If 
they are different, the Call Is a Cross-Procedure Object Call, described below. In the case of the Simple 
Mediated Call, the format field indicates that the location is an Entr/ Descriptor 47227. KOS Call microcode 
continues tiy saving the location of Entry Descriptor 47227 and creating a new Mediated Frame 46947 on 
current I^S Object 46703 and a new Ordinary SS Frame 10510 on SS Object 10336 for called Procedure 

6 602. As KOS Call microcode does so. It sets Fields 46917 and 46919 in Mediated Frame Header 10414 and 
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Relds 47109 and 471 1 1 in Ordinary SS Frame Header 10514 to the values required by the addition of frames 
to MAS Object 46703 and SS Object 10336. 

New Mediated Frame 46947 is now ready for Unkage Pointers 10416 to the actual arguments used in « 
the Call, so KOS Call microcode returns to S-tnterpreter Call microcode, which parses the SIN to obtain the 

^ Trteral spedfying the number of arguments and saves the literal value. S-interpreter Call microcode then 
parses each argument Name, evaluates it, and places the resulting value in Linkage Pointers Section 10416. 
When Unkage Pointers Section 10416 is complete, S-lnterpreter Call Microcode calculates the new location 
of FP from the location of the top of Unkage Pointers Section 10416 and places a pointer for the location In 
the FU 10120 register reserved for FP. At this time. S-interpreter Call microcode also places the new 
location of the top of the stack in Stack Top Offset Reld 46807. 

S-tnterpreter Call microcode then invokes KOS Call microcode to place the value of the literal 
specifying the number of arguments in MAS Frame Field 46929, to calculate the new value of FHP 46702 
and place it in the FU 10120 register reserved for that value, and finally to obtain the state necessary to 
execute called Procedure 602 from called Procedure 602's Entry Descriptor 47227 and PED 30303. As 
previously stated, S-interpreter Call microcode saved the location of Entry Descriptor 47227. Using this 
location, KOS Call Microcode obtains the size of the storage required for local data from Field 47233 and 
adds that amount of storage to the new MAS Frame 46709. Then KOS Call Microcode uses Reld 47231 to 
locate PED 30303 for Procedure S)2. PED ^03 contains the remainder of the necessary Information about 
Procedure 602 and KOS Call microcode copies the location of PED 30303 into PED Pointer Reld 46933 and 
then copies the values of K Raid 30305. Last Name Field 30307, NTP Reld 3031 1 and P8P Reld 3031 5 Imo 
the relevant registers In FU 10120. KOS Call microcode next translates the pointer in SiP Reld 30309 into a 
dialect number as explained in Chapter 3, and places it in register RDIAL 24212 of FU 10220 and thereupon 
derives SDP by resolving the pointer in SDPP Reld 30313 and a pointer to SEB 46864 by reserving the 
pointer in SEPP Reld 30316, Having performed these operations. KOS Call microcode returns to S- 

^ Interpreter Call microcode, which finishes the Call by obtaining a new PC, that is, resetting registers in I- 
stream Reader 27001 in FU 10120 so that the next SIN to be fetched will be the first SIN of called procedure 
602 S-intBrpreter Call microcode obtains the information required to change PC from Reld 47229 in Entry 
Descrlpttn- 47227 which contains the offset of the first SIN of called Procedure 602 from PBP, 

In the present embodiment some FU 10120 state produced by the Mediated Call SIN is retain^ on SS 

^ 504 throughout the duration of Procedure e02's invocation. The saved state allows Process 610 to 
reattempt the Mediated Call if the Call fails before the called Procedure 602 begins executing. When a 
Mediated Return SIN is executed, it resumes execution on the retained state from the CALL SINT. The 
Mediated Return is much simplerthan the Call. Since ail of the infonmation required to resume execution of 
the invocation which perfomed the Call is contained in Macrostate 10516 in the calling invocation's SS 

3ff Frame 47003, Return need only pop the called invocation's frames from currem MAS Object 46703 and SS 
Object 10336r copy Macrostate t(B16 47123 from the calling invocation's SS Frame 47003 into the proper 
FU 10120 registers, translate SIP Vakie 47141 into a dialect number, and resume executing tiie calling 
invocation. The pop operation involves nothing more than updating those pointers in MAS Object 46703 
and SS Ob^ 10336 which pointed to locations In the old topmost frame so that they now point to 

^ equWalent locations in the new topmost frame. 

cc. invocations of Procedures 602 Requiring SEBs 46864 (Fig. 270, 468, 469, 470, 471 , 472) 
If a Proi?edure 602 requites a SEB 46864, this fact is indicated by Flag Reld 47237 in Procedure 602's 
Entry Descriptor 47227. PED 30303 for such a Procedure 802 contains SEPP Reld 47225, whose value is a 

<5 non-resolvable pointer. The manner in which a SEB 46864 is created for Procedure 602 and SEPP field 
47225 is translated into SEP, a pointer which contains the location of SEB 4OT64 and is saved as part of the 
invocation's macrostate on SS 1 0336^ is similar to the manner in which a Static Data Block 46863 is created 
and the non-resoh^ble pointer contained in SDPP field 47225 is translated Into SDP. The first time that a 
Procedure 602 requiring a SEB 46864 is Invoiced on a MAS Object 46703. a SEB 46864 is created for the 

so Procedure 602 and an AATE 46857 is created which associates tiie nonresolvable pointer in SEPP field 
47225 and the location of SEB 4^64. That location is the value of SEP when tiie procedure is executing on 
MAS object 46703. On subsequent invocations of Procedure 602. AATE 46857 serves to translate the value 
in SEPP field 47225 into SEP. 

55 d.d Cross-Procedure Object Calls (Fig. 270, 468, 469, 470, 471, 472) 

A Mediated Call which invokes an External Procedure 602 is called a Cross-Procedure Object Call. As 
previously mentioned. KOS Call microcode assumes that any time the Name representing the called 
Procedure aJ2 in a Mediated Call SIN resolves to the location of a Gate that the Call is to an External 
Procedure 602. As long as newly-called External procedure 002 has the same DOE as calling Procedure 602. 
eo Cross-Procedure Object Calls differ from the Simple Mediated Call only in the manner in which called 
Procedure 602's Entry Descriptor 47227 is located. Once KOS Call microcode has determined as described 
above that a Mediated Call is a Cross-Procedure Object Call it must next detemnine whether it is a Cross- 
Domain Call. To do so, KOS Call microcode compares the tX)E Attribute of called Procedure 602's 
Procedure Object &3S with the domain component of the currem subject KOS Call microcode uses 
. ^ Procedure Object 608*8 AON 41304 to obtain Procedure Object 608's DOE from Reld 41521 of its AOTE 
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41306 and it uses the ASN for the current subject, stored In an FU 10120 register, to obtain the current 
subject's domain component fronr^ AST 10914, If the DOE and the current subject's domain component 
differ, the Call is a Cross-domain Call, described below; othenvise, the Call locates the Gate 47205 or 47206 
specified by the evaluated Name for called Procedure 602 in Its Procedure Object 60B. If the Gate is a Local 
5 Gate 47205, the Call uses Entry Descriptor Offset Reld 47207 to locate Entry Descriptor 47227 belonging to 
Celled Procedure 602 and then proceeds as described In the discussion of a Simple Mediated Call 

If the Gate is a Link Gate 47206, KOS Call microcode obtains the pointer corresponding to Link Gate 
47206 from Binder Area 47245 and resolves it to obtain a pointer to another Gate 47205 or 47205, whidi 
KOS Call microcode uses to repeat the External Procedure 602 call described above. The repetitions 
continue until the newly-located gate is a Local Gate 47205, whereupon Call proceeds as described for 
Simple Medial Calls. 

e.e. Cross-domain Calls (Fig. 270, 408, 418, 468, 469, 470, 471 , 472) 
tf a called Procedure GC^'s Procedure Object 608 has a DOE attribute differing from that of calling 
Procedure 602*$ Procedure Object 608, the Call Is a Cross-domain Call. The means by which KOS Call 
microcode determines that a Mediated Call is a Cross-Domain Call have previousiy been described; If the 
Call is a Cross-Domain Call, KOS Call microcode must inactivate MAS Object 46703 for the domain from 
which the Call is made, perform trojan horse argument chedcs, switch subjects, place a Cross-domain 
Frame 47039 on SS object 10336* and locate and acdvate MAS Object 46703 for the new domain before it 

20 can make a Mediated Frame 46947 on new MAS Object 46703 and continue as described in the discussion 
of a Simple Mediated Call. 

Cross-domain Call microcode first inactivates the current MAS Object 46703 by setting Domain Acthfe 
Bag 46804 to FALSE. The next step is the trojan horse argument checks. In order to perform trojan horse 
argument checks. Cross-domain Call must have pointers to the actual arguments used in the cross-domain 

2S invocation. Consequently, Cross-domain Call first continues like a non-oross-domain Call: It creates a 
Mediated Frame Header 10414 on old MAS Object 46703 and returns to S-interpreter microcode, which 
.evahiates the Names of the actual arguments, and places the pointers in linkage Pointers 10416 above 
Mediated Frame Header 10414. However, the macrostate for the invocation performing the call was placed 
on SS Object 10336 before Mediated Frame Header 10414 and Unkage Pointers 10416 were placed on old 

30 MAS Object 46703. Consequently, when calling Procedure 602 resumes execution after a Return, It will 
fBSume on MAS Frame 46709 preceding the one built by CrossHtomafn Call microcode. 

Once the pointers to the actual arguments are available. Cross-domain Call Microcode performs the 
trojan horse check. As described in the discussion of Procedure Object 608 and illustrated In Rgure 472, the 
information required to perform the check is contained in AiA 10352. Each l^ocal Gate 47205 in Procedure 

^ Object 608 has an AlAE 47245, each formd argument in Local Gate 47205's procedure has an entry in AIAE 
47245's AMA 47251, and the formal argumenfs AMAE 47253 imficates what kind of access to the fomwl 
argument's actual aiigument is required In called Procedure 602. 

Reld AIA OFF 47201 contains the location of AIA 10^ in Procedure Object 608, and using this 
information and Local Gate 47205's offset in Procedure Object 608, Cross-domain Call microcode locates 

40 AIAE 47245 for Local Gate 47205, The first two fields in AIAE 47245 contain the minimum number of 
arguments in the invocation and the maximum number of arguments. Cross-domain Call microcode 
checks whether the number of actual arguments falls between these values. If it does. Cross-domain Call 
microcode begins checking the access allowed indhndual arguments. For each argument pointer. Cross- 
domain Call microcode calls LAR microcode to obtain the current AON 41304 for the pointer's UID and uses 

45 AON 41304 and the ASN for Process 610*8 current subject (Le., the caller's subject) to locate an entry In 
either APAM 10918 or ANPAT 1G920, depending on whether the argument's AIAE specifies primitive access 
<47255| or extended access (47257) respectively. If the infomiation from APAM 10918 or ANPAT 10920 
confirms that Proc^ 610's current subject has the right to access the argument in the manner required in 
called Procedure 602, the Trojan Horse microcode goes on to the next argument If the current subject has 

SO the required access to all arguments, the trojan horse check succeeds and the Cross-domain Call continues. 
Otherwise, it falls and Cross-domain Call performs a microcode-to-software Call as explained below. 

Next Cross-domain Call microcode places Cross domain State 1(»13 on SS Object 10336. As explained 
in the discussion of SS object 10336, Cross-domain State 10513 contains the information required to return 
to the caller's frame on former MAS Object 46703. Having done this. Cross-domain Call microcode changes 

SS subjects. Using the current subjects ASN, Cross-Domain Call microcode obtains the current subject from 
AST 10914 replaces the subject's domain component with DOE Attribute 41225 for called Procedure 602's 
Procedure Object 608 and uses AST 10914 to translate the new subject thus obtained into a new ASN. That 
ASN then is placed in the appropriate FU 10120 register. 

After the subject has been changed. Cross-domain Call microcode uses Domain Table 41801 to 

6D trarislate the DOE of called Procedure 602 into a domain number. Cross-domain Call microcode then uses 
the domain number as an index into Array of MAS AONs 46211 In VPSB 614 for Virtual Processor 612 
belonging to Process 610 making the cross-domain call. The entry corresponding to the domain number 
contains AON 41304 of MAS Object 46703 for that domain. 

Having located the proper IMS Object 46703, Cross-domain Call microcode uses STO field 46807 In 

66 MAS Header 10410 belonging to the new domains MAS Object 46703 to locate the top of the last MAS 
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Frame 46709. It then saves the value of FHP 46702 used in the preceding invocation in a FU 10120 register, 
adds a Mediated Frame Header 10414 to the top of MAS Object 46703, and calculates a new FHP 46702 
which points to new Mediated Frame Header 10414. KOS Cross-Domain Call microcode then places the old 
value of FHP 46702 In FHP Value Field 47151 of SS Object 10336 and the old value of STO 46704 {pointing to 
^ the top of the last complete MAS Frame 46709 on previous MAS Object 46703) in Field 47153 of Cross- 
Domain State 10513 and fills In Mediated Frame Header 10414 fields as follows: Result of Cross-domain 
Call Reld 46903 is set to TRUE. Previous Frame Offset Field 46917 is set to 0, and Dynamic Back Poimer 
Field 46931 is set to the saved value of FHP 46702. Dynamic &ack Pointer Reld 46931 thus points to the 
header of the topmost Mediated Frame 48947 on the previous MAS Object 46703. The values of the 
remaining fields are copied from Mediated Frame Header 10414 which Cross-Donnain Call created on 
previous MAS Object 46703. 

Cross<iomain Call microcode next copies the argument pointers for the formal arguments from the top 
of previous MAS Object 48703 to new Mediated Frame 46947 and calculates FP. Cross*domain Call 
Microcode finishes by returning to Snnterpreter Call microcode^ which completes the Call as described for 
Simple Mediated Calls. 

Except for the woric involved in transferring to a new MAS Object 46703, Cross-domain Return is like 
other Returns from Mediated Calls. Old FHP 46701 from Reld 47151 of Cross-Domain State 10513 and old 
STO 46704, from Reld 47153 of Cross-domain State are placed in FU 101 20 registers. Then the frames 
belonging to the invocation that is ending are popped off of SS Object 10336 and off of MAS Object 46703 

^ belonging to the domain of called Procedure 602 and MAS Object 46703 is inactivated by setting Domain- 
Active Rag 46804 to FALSE. Then KOS Cross-domain Return microcode uses old FHP 46701 and old STO 
46704 to locate MAS Object 46703 being returned to and the topmost Mediated Frame 46947 on that MAS 
Object 46703. MAS Object 46703 being returned to is activated, and finally, the contents of Macrostate 
1051 6 belonging to the invocation b&ng returned to are placed In the appropriate n&gisters of FU 1 01 20 and 

^ execution of the invocation resumes. 

f.f. Failed Cross-Doamin Calls (Fig. 270. 468. 489, 470, 471, 472) 
A Cross-Domain Call as described above may fail at several points between the time that the calling 
Invocation begins the call and called Procedure 602 begins executing. On failure, Cross-Domain Call 

^ microcode performs a microcode-to-software Call. KOS Procedures 602 invoked tiy ^is Call may remedy 
the reason for the Cross Domain Call's failure and reattempt the Cross-domain Call. This is possible 
because the implementation of Cross Domain Call in CS 10110 saves suffidem FU 10120 state to allow 
Process 610 executing the Cross-Domain Call to return to the invocation and the Mediated Call SIN from 
which the Cross-Domain Call began. On failure^ the invocation's MAS Frame 46709 may be located from 

^ the values of STO Held 47153 and FHP Field 47151 in CrossrDomain State 10513, and the Mediated Call SIN 
may be located by using information saved in FU 10120 state. 

a Neighborhood Calls (Rg. A6B. 479, 472) 

As previously nnentioned. Procedures 602 called via Neighborhood Calls must have the same PED 

^ 30303 as calling Procedure 602. The only macrostate values which are not part of PED 30303 are PC and FP; 
consequently N^ghborhood Call need only save PC and FP of the Invocation performing the call and 
calculate these values for the new invocation. In addition. Neighborhood Call saves STO 46704 in order to 
make it easier to locate the top of the previous Invocation's Neighborhood Frame 46947. N^ghborhood 
Return simply restores the saved values. Since the macrostate values copied from or obtained via PED 

4S 30303 do not change during the sequence of invocations, and therefore need not be sav^ on SS Object 
10336. Neighborfiood Calls do not have SS Frames 47003. 

The invention may be emtx>dfed in yet other sp^tfic forms without departing from the spirit or 
essential characteristics thereof. Thus, the present embodiments are to be considered in all respects as' 
Illustrative and not restrictive, the scope of the invention tming indicated by the appended claims rather 

50 than by the foregoing description. 

Claims 

1. A digital computer system (CS 101) including processor means (JP 114) for performing operations 
£5 upon operands, memory means (MEM 112) for storing said operands and procedures* said procedures 
including instructions for controlling said operations and names referring to certain of said operands to be 
operated upon, ALU means (2034, 2074) for performing said operations, bus means (MOD 140, JPB 142) for 
conducting said instructions, names and operands between said memory means and said processor 
means, and 1/0 means (lOS 116) for conducting at least said operands between said memory means and 
60 devices external to said digital computer system, characterised in that ^id processor means (JP 114) 
comprises means for addressing said operands, including name table means (10350) for storing name 
table entries, each name table entry corresponding to one of said names included in each one of said 
procedures and each name tatrfe entry comprising first data from which may be determined an address of a 
location in said memory means of the operand referred to by one of said names and second data 
& identifying a format of that operand, and translation means (NAME TRANS UNIT 27015} connected to said 
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bus means and responsive to said name table entries for providing outputs to said memory means 
representing said addresses, and further characterised in that said instructions are intermediate level S- 
language Instructions from a plurality of sets of such instructions, each set corresponding to a particular 
higher level user programming language, and further characterised by receiving means {INSTB 20262) 
connected to said bus means for receiving said instructions from said memory means, and microcode 
control means (10240. 27003, 27013) connected between said receiving means and said ALU means for 
providing sequences of microinstructions for controlling said ALU means, said sequences being selected 
from a plurality of sequences of microinstructions corresponding to said S-language Instructions 
fespectively. 

2. A digital computer system according to claim 1, characterised In that the S-ianguage instructions 
have a uniform, fixed format 

3L A digital computer system according to claim 1 or 2, characterised in that the names are of uniform 
length and format 

4. A digital computer system according to any of claims 1 to 3, characterised in that each procedure 
« further includes a name table pointer (NTP 30311) representing a base location in said memory means 

(MEM 112), and said first data of each name table entry contains information from which maybe 
determined an address offset of a memory location relative to the base location, and In that said translation 
means (NAME TRANS UNIT 27015) further comprises base register means (NCR. MCR 10366) connected to 
said bus means for receiving and storing said name table pointer of the procedure currently controlling the 
^ operations performed by said ALU means. 

5. A digits computer system according to any of claims 1 to 4, characterised by name cache means 
(10226) connected to outputs of said translation means (NAME TRANS UNIT 27015) and having outputs to 
said memory means (MEM 112) for storing said addresses, and further connected to said receiving means 
(INSTB 20262) and responsive to said names to pnonde name cache outputs to said memory means 

25 representing addresses of certain operands for which said name cache means has stored said 
addresMs. 

& A digital computer system aocorcGng to any of claims 1 to 5, characterised in that each of said S- 
Language instructions is a member of an S-Language dialect of a pluiatity of S-Language dialects, and in 
that said rec^ng means (INSTB 202^ further comprises dialect code means (BDtAL 24212) for storing a 
30 dialect code specifying the dialect of which the receded S-Language instructions are members, and in that 
said sequences of microinstructions include a set of sequences of microinstructions, corresponding to each 
said S-Language dialect, each set of sequences of microinstructions including at least one sequence of 
microinstrucdons corresponding to each S-Language instruction In a corresponding S-Language dialect, 
and In that said microcode control means (10240, 27003, 27013) is responsive to the dialect code and to 
3S each receded S-Language Instruction to provide to said ALU means (2034, 2074) a sequence of 
microinstructions corresponding to that S-Language instruction. 

7. A (£gital computer system according to claim 1 or 2, characterised in that each procedure Includes a 
dialect code deiKiting an S-Language dialect of which the S-Language instructions of the procedure are 
members, and In that said microcode control means (10240, 27003, 27013] further comprises control store 
4)9 means (STTT 11012) for storing said sequences of microins^uctions for controlling said ALU means (2034, 
2074), and dispatch table means (SIDT 11010) for storing addresses corresponding to locations in said 
control store means of each sequence of microinstnictions, and in that said dispatch table means is 
responsive to said dialect code and to each instruction to provide to said control store means each address 
corresp(H)ding lo said at least one microinstruction sequence corresponding to each said instruction, and 
45 said control store means Is responsive to each address to provide to said ALU means said sequence of 
microinstructions corresponding to each Instruction. 

a A digitel computer system according to claim 1 , 6 or 7, characterised in that said microcode control 
means (10240, 27003, 27013) comprises writable control store means (11012) connected to said bus means 
for storing said sequences of microinstructions, and control store addressing means (SITTNAS 20266) 
so responsive to each S-Language instruction and to operation of said processor means for generating control 
store read addresses and write addresses (CSADR 20204), and in that said writable control store means is 
responsive to said read addresses to provide said sequences of microinstructions to said ALU means (2034, 
2074) and is responsive to said write addresses to store said sequences of microinstructions^ 

9. A digital computer system according to claim 7, characterised in that said control store means (SITT 
S5 1 101 2) comprises writable control store means connected to said bus means for storing said sequence of 
microinstructions, and in that said dispatch table means comprises write address means responsive to 
operation of said processor means for generating write addresses, and in that said writable control store 
means is responsive to said write addresses for storing said sequences of microinstructions. 

€0 Patentanspruche 

1, Digitales Datenverarbeitungssystem (CS 101), enthaltend: Prozessormittel (MEM 114) zur 
Durchfuhrung von Operationen an Operanden, Spelchermittel (MEM 112) zum Speichem der Operanden 
und von Prozeduren, die Befehle zur Steuerung der Operationen und Namen enthalten, die auf gewisse der 
es Operanden Bezug nehmen, an denen Operationen durchgefOhrt werden sollen, eein Rechenweric (2034, 
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2074) zur Durchfuhrung der Operationen, Bus-Mittel (MOD 140, JPE 118) fOr den Verkehr der Befehie, 
Namen und Operanden zwischen den Speicheimitteln und den Prozessomnhteln, und Eingabe/Ausgabe- 
MIttel (lOS 116) fur den Verkehr wenigstens der Operanden zwischen den Speichermtttein und Geraten 
au&erhalb des digitaten Datenverarbeitungssystems, gekennzeichnet durch Prozessormittel {JP 114], die 
Mittel zur Adressierung der Operanden einschlieBlich Namenstabellenmittei (10350) zur Speicherung von 
Namenstabellen-Einsprungpunkien enthalten, wobei jeder Namenstabeflen-Einsprungpunkt eincm der 
Namen entspricht die in jeder der Prozeduren enthalten sind« und erste Oaten, aus denen eine Adresse 
elnes Platzes derjenigen Operanden in den Speichermitteln bestimmt werden kann, auf die durch einen der 
Namen Bezug genommen wird, und zwelte Oaten enthatten die ein Fomiat dieses. Operanden identifH 
deren, und durch Ubersetzungsmittei (NAME TRANS UNIT 27015), die mit den Bus-Mitteln verbunden sind 
und auf die Namenstabellen-Einsprungpunkte unter Berettstellung von diese Adressen reprasentierenden 
Ausgaben fur die Spelchermittel ansprechen, femer dadurch gekennzeichnet da& die Befehie mittlere S- 
Sprache-Befehte von einer Vielzahi von Satzen solcher Befehie sind, von denen jeder Satz einer 
b^onderen hoheren Benutzerprogrammiersprache entspricht, und femer gekennzeichnet durch ein mit 
den Bus-Mitteln verbundenes Empfangsmittei (INSTB 20262) zum Empfang der Befehie von den Speicher- 
mitteln, und durch mit dem Empfangsmittei und dem Rechenwerk verbundene Mikrocode-Steuermlttel 
(10240, 27003, 27013) zur Bereitstellung von Mikrobefehlssequenzen zur Steuerung des Rechenwerks, 
wobei diese Sequenzen aus einer Vielzahi von Mikrobefehlssequenzen ausgewahit sind, die den jeweiligen 
S-Sprache-Befehlen entsprechen. 

2. Digitales Oatenverart>eltungssystem nadi Ansprvch 1, dadurch gekennzeichnet, daB die S-Sprache- 
Befehie ein gleichformiges, festes Format haben. 

3. Digitales Datem/erart^ertungssystem nach Anspruch 1 Oder 2, dadurch gekennzeichnet* daB die 
Namen eine gleichfomiige Lange und ein gleichformiges Format haben. 

4. Digitales Datenverarbeitungssystem nach einem der Ansprucha 1 bis 3, dadurch gekennzeichnet, 
daG jede Prozedur welter einen Namenstabellera^iger (NTF 30311) enthait, der einen Basisplatz in den 
Spetchermitteln (MEM 112) reprasentlert daB die ersten Oaten jedes Namenstabellen-Einsprungpunktes 
Informationen enthalten, aus denen die Adresse elnes vom Basisspeicherplatz versetzten Speicherplatzes 
bestimmt werd^i konnen, und dai^ die Ubersetzungsmittei (NAME TRANS UNIT 27015) we'rter Baslsregl- 
stermittel (NCR, MCR 10366) enthalten, die mit den Bus-Mitteln verbunden sind, um den Nannenstabelten- 
zeiger derjenigen Prozedur zu empfangen und zu speicherUt die gerade die vom Rechenwerk durch- 
gefuhrten Operations steuert. 

5. CHgitales Datenverarbeitungssystem nach anem der AnsprOche 1 bis 4, gekennzeichnet durch 
Namens-Cache-Speichermittel (10226), die mit den Ausgangen der Obersetzungsmittel (NAME TRANS 
UNfT 27015) verbunden sind und zu den ^>eichermitte(n (MEM 112) fOhrend Ausgange zum Speichem der 
Adressen haben, und die weiter mit dem Empfangsmittei (INSTB 20262) verbunden sind und auf die 
Namen unter Bereitstellung von Namens-Cache-Ausg^n fur die Speichermittel ansprechen, die die 
Adressen von gewissen Operanden reprSsentieren, fur die die Namens-Cache-Spetchemrilttel die Adressen 
gespeichert haben. 

6. Digitales Datenverartwitungssystm nach eirmm der Anspruche 1 bis 5, dadurch gekenrueichnet, 
daB jeder der S^prache-Befehle ein Mitglied eines S-Sprache-Dialekts einer Vielzahi von S-Sprache- 
Dialekten 1st, daB das Empfangsmittei (INSTB 20262} weiter ein Dialekt-Code-Mittel (RDIAL 24212) zur 
Speicherung eines Dialekt-Codes enthalt, der den Dialekt bestimmt, von dem die empfangenen S-Sprache- 
Befehie Mitglleder sind, daB die Mikrobefehlssequenzen einen Satz von Mikrobefehlssequenzen ent- 
sprechend jedem S-Sprache-Dialekt enthalten, wobei jede Mikrobefehlssequenz wenigstens eine jedem S- 
Sprache-Befehl In eInem entsprechenden S-Sprache-Dialekt entsprechenden Mikrobefehlssequenz enthSIt 
und dall die Mikrocode-Steuermittei (10240, 27003, 27013) auf den Dtalekt-Code und Jeden empfangenen S- 
Sprache-Befehl unter Bereitstellung einer diesem S-Sprache-Befehl entsprechenden Miicrobefehlssequenz 
fur das Rechenwerk ansprechen. 

7. Digitales Datenverarbeitungssystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, daB jede 
Prozedur einen Dialektcode enthalt, der einen S-Sprache-Dialekt bezeichnet, von dem die S-Sprache 
Befehie der Prozedur Mitglieder sind, daB die Mikrocode-Steuermfttel (10240, 27003, 27013) femer Steuer- 
spelchermittel {SITT 11012) zur Speicherung der Mikrobefehlssequenzen fur die Steuerung des Rechen- 
werks (2034, 2074) und Veneilertat>ellenmrttei (SIDT 11010) zur Speicherung von Adressen enthalten, die 
Platzen jeder Mikrobefehlssequenz in den Steuerspeichermrtteln entsprechen, und da{^ die Verteiler- 
tabelienmrttei auf den Dialektcode und jeden Befehl unter Bereitstelluiig jeder Adresse, die der wenigstens 
einen, zu jedem Befehl gehdrenden Mikrot)efehlssequenz entspricht, fur die Steuerspeicherm'rttel 
ansprechen, wahrend die Steuerspeichermittel auf jede Adresse unter Bereitstellung der jedem Befehl ent- 
sprechenden Mikrobefehlssequenz fOr das Rechenwerk ansprechen. 

a Digitales Datenverarbeitungssystem nach Anspruch 1, 6 oder 7, dadurch gekennzeichnet, daB die 
Mikrocode-Steuermittel (10240, 27003, 27013) ein mit den Bus-Mitteln verbundenes Schreibsteuerspeicher- 
mittel (11012) zur Speicherung der Mikrobefehlssequenzen und Steuerspeicheradressiermittel (SITTNAS 
20286) enthatten, die auf jeden S-Sprache-Befehl und auf Operationen des Prozessormittels unter 
Erzeugung von Steuerspeicherlese- und -schreibadressen (CSADR 20204) ansprechen, und daE die 
Schreibsteuerspeichermittel auf die Leseajdressen unter Bereitstellung der Mikrobefehlssequenzen fur das 
Rechenwerk und auf die Schreibadressen unter Speicherung dieser Mikrobefehlssequenzen ansprechen. 
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9. Digitales DatenverarbeHungssystem nach Anspruch 7, dadurch gekennzeichnet, daS dib Steuer- 
spetehermlttel (StTT 11012) mlt den Bus-Mittein verbundene Schreibsteuerspeichermittel zur Speicherung 
der Mikrobefehlssequenzen enthahen, daB die Vertellertabellenmittel Schreibadr^senmittel enthalien, die 
auf Operationen des Prozessormittels unter Erzeugung von Schrelbadressen ansprechen, und daB die 
Schreibsteuerspeichermittel auf die Schreibadressen unter Speicherung der Mikrobefehlssequenzen 
ansprechen. 

Revendicatlons 

1. Un syst^me d'ordinateur num^rique (CS 1 01 ). comprenant un processeur (JP 114) pour effectuer des 
operations sur des operandes, une memoire (MEM 112) pour m^moriser lesdits op^randes et des 
procedures, iesdrtes procedures contenant des instmctions pour commander lesdites operations et des 
desigrtations se rapportant d certains desdits operandes pour les tralteo une unite arithmetique et togique 
ALU (2034, 2074) pour effectuer lesdites operations, des bus (MOD 140, JPB 142) pour transmettre iesdites 
instructions, lesdites designations et lesd'tts operandes entre ladite memoire et ledit processeur, et des 
moyens d'entree/sortie I/O (lOS 116) pour transmettre au moins lesdits operandes entre ladite memoire et 
des (fisposhifs exteneurs audit systdme d'ordinateur numerique, caracterise en ce que tedit processeur ( JP 
114) comprend des moyens pour I'adressage desdits operandes, comportant une table de designations 
(10350) pour memoriser des entrees de table de designations, chaque entree de table de designations 
correspondaht a une desdites designations incluses dans diacune desdites procedures et chaque entree de 
table de designations comprenant une premiere donnee a partir de laquelle peut etre determinee une 
adresse d'un emplacement de ladite memoire contenant I'operande auquel se reflete fune desdrtes 
designations et une seconde donnee Identifiant un format de cet operande, et des moyens de transcodage 
(NAME TRANS UNIT 27015) relies auxdits bus et reagissant auxdites entrees de tables de designations de 
fagon d transm^tre k ladite memoire des signaux de sortie representant lesdites adresses, et en outre 
caracterise en ce que lesdites instructions som des instructions en iangage*S de nhreau intermediaire 
provenant d'une piuralite d'ensembles de telles Instructions, chaque ensemble correspondent e un 
langage de programmation par utilisateur de niveau superieur partlculier, et en outre caracterise en oe que 
des moyens de reception (INSTB 20262] sont relies auxdits bus pour reoevoir lesdites instructions k partir 
de ladite memoire, et des moyens de commande de microcode (10240, 27003, 27013) connectes entre 
lesdits moyens de reception et ladite ALU pour foumir des sequences de microinstructions servant a 
cornmander ladite ALU, les dites sequences eiant setectionnees panml une piuralite de sequences de 
micro-insuuctions correspondent respectivement auxdites instructions en langage-S. 

Z Un systeme d'ordinateur numerique selon la revendication 1, caracterise en ce que les (nstructions 
en langage<S ont un format fbce et uniforme. 

3. Un systeme d'ordinateur numerique selon une des revendications 1 ou 2, caracterise en ce que les 
designations ont une longueur et un format unlformes. 

4- Un systeme d'ordinateur numerique selon une quelconque des revendications 16 3, caracterise en 
oe que chaque procedure comprend en outre un pointeur de table de designations (NTP 3(D11| 
repre&entant un emplacement de base dans ladite memoire (MEM 112) ^ ladite premiere donnee de 
chaque entree de la table de designations contient une infomnation a partir de laquelle peut etre determine 
un decalage d'adresse d*un emplacement de memoire par rapport d i'emplacement de base, et en ce que 
lesdits moyens de transcodage (NAME TRANS UNIT 27015) comprennent en outre un moyen formant 
registre de base (NCR, MCR 1 0366). qui est relie auxdits bus de fagon k recevoir et memoriser ledit pointeur 
de table de designations dans la procedure qui est en train de commander les operations effectuees par 
ladite ALU. 

5, Un systeme d'ordinateur numerique selon une quelconque des revendications 1^4, caracterise par 
un moyen formant antememoire de designations (10226), relie aux sorties desdits moyens de transcodage 
(NAME TRANS UNIT 27015) et comportant des sorties reliees ^ ladite memoire (MEM 112) pour memoriser 
lesdites adresses, et en outre relie auxdits moyens de reception (INSTB 20262) et r6agissant auxdites 
designations pour foumir h ladite memoire des sorties de Tantememoire de designations representant 
iesdites adresses de certains operandes pour lesquels ladite antememoire de designations a memorise 
lesdites adresses. 

6. Un systeme d'ordinateur numerique selon une quelconque des revendications 1^5, caracterise en 
ce que chacune desdites instructions en langage-S est un element d'un dialecte en langage-S faisant partie 
d'une piuralite de dialectes en langage-S et en ce que lesdits moyens de reception (INSTB 20262) 
comprennent en outre un moyen de codage de dialecte (RDIAL 24212) pour memoriser un code de dialecte 
sp6cifiant le dialecte dont les instructions en langage-s regues sont des elements, el en oe que lesdites 
sequences de micro-instructions contiennent un ensemble de sequences de micro-instructions 
correspondant h chacun desdits dialectes en iangage-S, chaque ensemble de sequences de micro- 
instructions comprenant au moins une sequence de micro-instructions correspondant h chaque instruction 
en langage-S dans un dialecte en langage-S correspondant, et en ce que lesdits moyens de commande de 
microcode (10240, 27003, 27013) reagissent audit code de dialecte et d chaque Instruction en langage-S 
regue pour fournir d ladite ALU (2034, 2074) une sequence de micro-instructions correspondant ^ cette 
instruction en langage-S. 
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7. Un syst^e cf ordinateur numeiique selon une des revendlcati'ons 1 et 2, caract^risd en ce que 
cheque procedure comprend un code de dialecte definissant un dialecte en langage-S dont les instructions 
en langago-S de la procedure sent des elements et en ce que lesdits moyens de commande de microcode 
{1020, 27003, 27013 comprennent en outre une m6moire de commande (SITT 11012) pour mdmoriser 

S lesdites sequences de micro-instrucdons pour commander ladite ALU (2034, 2074), et un moyen a table de 
distribution {SIDT 11010) pour menfw>ri$er des adresses correspondent aux emplacements de cheque 
sequence de micro-instructions dans ladKe memoire de commande, et en ce que ledit moyen a table de 
distribution r^it audit code de dialecte et i chaque instrucdon pour foumir a ladite memoire de 
commande chaque adresse correspondant a ladite sequence de micro-instructions au moins prevue 

w cDrrespondant ^ chacune desdites instructions, et ladite m6moire de commande reagit a chaque adresse 
pour foumir d ladite ALU ladite sequence de micro-instructions correspondant ^ dx^que instruction. 

8. Un systeme h ordinateur num6rique selon une des revendications 1, 6 et 7, caracterise en ce que 
lesdits moyens de commande de microcode (10240, 27003. 27013) comprennent une memoire de 
commande Inscriptible (11012) reliee auxdits bus pour m^moriser lesdites s^uences de micro-instructions 

IS et un moyen d'adressage de memoire de commande (SITTNAS 20286) reagissant a chaque instruction en 
langage-S et au fonctionnement dudh processeur pour produire des adresses de lecture et des adresses 
d'ecriture dans la memoire de commande (CSADR 20204) et en ce que ladite memoire de commande 
inscriptibie reagit auxdltes adresses de lecture pour foumir lesdites s^uences de micro-instructions a 
ladite ALU (2034, 2074) et reagit auxdrtes adresses d'ecriture pour mdmoriser lesdites sequences de micro- 

20 instructions. * 

9. Un systeme d'ordinateur numSrique selon la revendicetion 7, carect^ris^ en ce que ladite memoire 
de commande (SITT 11012) comprend une memoire de commande inscriptible qui est reliie auxdits bus de 
mimonser lesdites sequences de micro-instructions et en ce que ledit moyen ^ table de distribution 
comprend un moyen d'adressage d'teriture reagissant au fonctionnement dudit processeur pour produire 

2S des adresses d'toiture. et en ce que la m6moire.de commande inscriptible reagit auxdites adresses 
d'ecriture pour mimonser lesdites s^uences de microHr^structions. 
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